I agree with Charles...good engineering skills does not necessarily translate to any sort of cleverness or creative aptitude. In fact, you can find a lot of smart people who do not have solid engineering skills (or may not even know how to develop), but who have great minds and have far reaching visions for CS in general.
I also feel like, in questioning the competency of your workplace you're jumping the gun a little. I just recently graduated and I know very well that in academia everything is all fine and dandy. Code is fully unit tested, proper design patterns are followed, algorithms are tested for correctness and efficiency, and the right frameworks are used. However, in actual industry some sacrifices are (unintentionally) made in order to meet deadlines and to serve business goals. Sometimes a project is just "good enough" to be deployed. Also, a lot of times, there is an intent to ship a version 0.5 of a project that may have a lot of questionable design decisions, but on the surface is functional enough to showcase capabilities, and will later evolve into something more structured and well designed.
So, you really can't expect it to always be all rosy...I'm sure even at Microsoft new projects start off with weird design decisions because everyone is focused on the concept (take the Kinect SDK beta, e.g.). But then through subsequent iterations, they start to slowly improve the project, bringing it to something really high quality.
My suggestion to you is to stop worrying about the frameworks and the design patterns (or lack thereof) that you're forced to use. Focus on the problem and the solution...and have fun doing it! I've worked with crappy codebases in the past too and I can definitely say that I enjoyed those projects in which I got to start from scratch the most. However, the most rewarding projects to me were the ones that solved an interesting problem - when you're solving a problem, the actual coding practice doesn't seem to matter so much.
If you REALLY want to work with such software engineering structure, then you should think about roles/positions dealing with high integrity data/products (financial, systems software, rdms design). But these types of positions are also insanely boring in my opinion. It depends on what you like - I think you should focus on the problems you like to solve rather than how those problems are solved IMO. You'll be more satisfied.
BTW, on the topic of solving problems, design patterns are problem solving utilties. They are not one size fits all...they're tried and tested resources for solving common design issues. If the issue does not exist and you cannot forsee it coming about because of business processes or the structure of your technology, then there really is no reason to be using it. Furthermore, design patterns come with limitations, usually along the lines of adding additional layers of abstraction and indirection that might impact performance or add unnecessary complexity to an otherwise simple application.