It sounds like your problems are more general.
The refactoring issue is both a symptom and a potential relief from part of the problem.
The Software Lead and the Team Allocate the Team's Time
From my experience, I think you may be encountering a problem that I call, "everybody's a software manager." Product managers, project managers and sometimes system engineers and testers can be notorious for trying to micro-manage developers who probably already have an experienced software manager. You may even have a few members on your team who believe their role is to manage.
If you are the software manager, make assignments for the refactoring you want, or better yet, have your team propose refactoring to you for your approval. So as to not micromanage, you might have guidelines about age/author/size/context of code to be refactored that can be freely refactored vs. needing approval. If a member of your team wants to massively refactor four big classes of complex old code he didn't write that are not part of his feature, his two week diversion is your problem, so you need a chance to say no.
You can sneak around, but I think it is better to just build your estimates carefully with time for analysis, design, coding, multiple forms of testing (at least unit and integration), refactoring, and risk as judged historically and by the lack of experience or clarity associated with the task. If you have been too open about the workings of your team (or have members on your team who are), it might be wise to narrow communications channels so they go through you and discuss resources and results, not methods.
Early Project Choices Create a Vicious Cycle for Refactoring
Software maintenance is hard. It is doubly hard if others in the organization are making choices at your expense. This is wrong, but it is not new. It has been addressed by Barry Boehm who is one of our great software writers who puts forward a management model he describes as Theory W.
Often software developers are hammered to produce under the Theory-X management approach that says that workers are basically lazy and will not perform unless pounded into submission. Boehm summarizes and contrasts his proposed model as follows:
"Rather than characterizing a manager as an autocrat (Theory X), a coach (Theory Y), or a facilitator (Theory Z), Theory W characterizes a manager’s primary role as a negotiator between his various constituencies, and a packager of project solutions with win conditions for all parties. Beyond this, the manager is also a goal-setter, a monitor of progress towards goals, and an activist in seeking out day-to-day win-lose or lose-lose project conflicts, confronting them, and changing them into win-win situations. "
Quick and Dirty is often Just Dirty
Boehm goes on to point out the reason things are so miserable for developers on the maintenance team.
"Building a quick and sloppy product may be a low-cost, near-term “win” for the software developer and customer, but it will be a ‘‘lose’’ for the user and the maintainer." Please note that in Boehm's model, the customer is more of a contract administrator instead of an end user. In most companies, think of the product manager as a customer surrogate, or perhaps the person who buys the product for its feature list.
My solution would be to not release the original development team (or at least the original lead) until the code is refactored to at least meet coding standards.
For customer , I think it is reasonable to count the product manager as a customer surrogate, and the group of people rewarded for delivering something quick and dirty can certainly be expanded, so there is a big constituency for doing things the wrong way.
Refactoring is not Negotiable
Please don't back down from your role as a software manager. You should have authority and discretion to use your team's time in process and product improvements. In that role, you may need to negotiate your choices to make your team more professional. However, with regard to process, don't negotiate with marketing, because in my experience, that is a losing game. Negotiate with engineering management. It shows you have vision. Building a professional software team is an extension of their role, and is much more likely to be seen as a win-win.