How do I implement process at my first job when I only barely know what I am doing?
Implementing processes requires authority, which is generally held by management. You'd need management's active support, but it would be very weird if you, a junior developer without neither much experience nor reputation in the company, were given such power.
All you can realistically hope for is make suggestions in the right ears, but again, this will only work if the person in question is receptive, which generally requires building some trust first. Of course, if they actually ask for suggestions, go ahead and prepare some, but otherwise the most likely result is annoying busy people that have much influence over your future career.
Should I try to get out of here before I develop bad habits or is this a right of passage? (Ive only been here a few weeks, how long should I wait?)
First, on all but the smallest of companies process changes take months, not weeks, to fully implement, in particular if the management team is kept busy by other things.
As for developing bad habits, I am not convinced you would. After all, you seem aware their process is bad, and aware of the damage it causes. In contrast, seeing such consequences illustrated vividly on a daily basis seems a great way to learn what to never do :-)
One of my first jobs featured a technical lead that had some very particular failings. I suffered from them, and learned what to never do if I ever became lead. When I was promoted years later to a technical leadership role, those memories helped me avoid mistakes I might otherwise have made. Or to put it differently: "nobody is useless: they can always serve as a bad example" :-)
But back to you: Being in a company with a bad process will teach you that this process is bad, but won't teach you a good process. So, if after a while process does not improve, it may be advisable to switch companies (and remember to ask about process in the interview, if you do).
In the meantime, there is another valuable skill you can learn in this company:
Basically the code has no documentation [...] most of my time is spent haphazardly attacking really difficult bugs
Tracking down bugs in undocumented code written by people no longer available for questions is a skill you will need many times in your career, because even the guys with 100% code coverage sometimes find the cause of a bug in sparsely documented library code written by other people.
So, should you stick around or leave? That depends on you, and numerous factors that are hard to communicate in a Q/A site. But personally, I see nothing in your post that would truly trouble me in the short term, so personally, I'd probably stick with this company for a year and then reassess the situation: Has process improved? Can I now learn the other things that make a developer or am I still stuck firefighting? Am I happy in my job?
The reason for waiting is that leaving a job after less than a month looks odd on a resume, so you'll only want to do this if necessary (your local cultural norms on this may vary, but such is the case where I live). The second reason is that they might come around, and improve process, giving you the opportunity to get a reputation for making good suggestions, which will help your career. And third, unlikely as it may seem, perhaps the process they use is not as dysfunctional it appears at first glance, and isn't limiting your career after all.
