I will start off by saying that I have a messy legacy project that I work on and try to improve where I can, and I
also would prefer to rewrite and start over. I haven't been fully successful at either approach yet myself, but I have made
some progress, at least, so I can share some thoughts.
First, if they have "brought" you in and now expect you alone to fix things while they continue business as usual, that's a setup for failure all around. They need to "buy in" as much as you have, and everyone needs to establish some guidelines and expectations ahead of time.
Presumably, they have already bought in to the notion that things need to improve if you've been tasked with this at all, which is good (I don't always have this benefit). But it's not enough to bring somebody like yourself in, and then just continue business as usual.
So, first order of business - try to find a couple areas of the app that is a good combination of (1) relatively self-contained, (2) less of a moving target, and (3) able to provide visible gains when improved.
You might not be able to hit all 3 points, but find a good balance that gives a good bang for the buck.
For example, if one of your problems is data acquisition is too tightly coupled with view code, that might be a huge problem spread all over the place. So, find a subset of the problem -- something that gets used frequently (maybe, user login status? user permissions?) but is changed less frequently relative to other things.
Once you have a few suggestions, work with the team to agree upon ONE area. Take a little time to plan out how you want to improve it and why, and then propose your solution to the rest of the team.
With that done, get everyone to agree -- this one piece shouldn't be changed during your first "sprint" on this item without your involvement in guiding its direction.
I would suggest regularly updating the team on your progress and letting them in on any decisions you make along the way. The more they can be involved and help, the better.
The end goal is to end up with something that everyone has a little bit of ownership in, AND something with visible improvements such that the rest of the team will want to continue working with it "the right way" rather than piling on top "the old way".
Once done, try to find another feature and work it out the same way. In time, hopefully more developers will be more "sold" on newer patterns for development that you help establish, and will be more inclined to follow them when adding new code.
If this approach can't work for refactoring code, something similar can happen with a rewrite.
But there are two unfortunate problems that I continue to run into and don't know if they can be overcome.
1. If management insists you can work a miracle without the rest of the team needing to modify behavior, work alongside you, or include you in prioritizing or estimating new features, then the whole task is unrealistic.
2. If the developers working on the project are hostile to your efforts, have no desire to modify their practices and learn new patterns, or continually and stubbornly resort to old habits, then you will be fighting an uphill battle, even if you were to hand them a newly rewritten app.