I think it's important to schedule time for dealing technical debt if you are trying to make up for old sins, but I also think you should not make this a habit. Once you clean up the mess you should avoid putting your project into more debt, unless you have good reasons for doing so.
Actively managing it like Mike suggests seems like the most reasonable approach, but I think it's very important to make it clear (to your team) that you should not schedule time or plan for refactoring in the long run.
Refactoring should be a natural part of writing code, and thus should be included in your other estimates and plans, and not be treated as a separate activity—unless you have to, i.e for "historical" reasons or because you consciously decided to implement something a given way and then re-implement it later.
