Tagging is a very cheap operation in subversion. Tag your code when you start refactoring and at regular stages while you go along. That way it's easy to still access the old (but functional code) as a reference for your shiny new (but broken code). :-)
All code becomes 'legacy' one day, why seperate it at all? Source control is by project/branch or project/platform/branch and that type of hierarchy. Who cares how long in the tooth it is?
Use svn:externals to reference your legacy code as you would a third-party repository.
Then you can separate your refactoring work from your dependent projects and (using fixed revision references i.e. -r1234) be very explicit about which revision of the legacy code the dependent project depends on.
Here's your free psychological analysis:
What you have here is a deep-rooted desire to fix your legacy code so that it's not legacy anymore. When you hide it away, you're just repressing that desire, trying to avoid it because it's an uncomfortable feeling. If you leave it out in the open, one of two things will happen: it'll eventually drive you and insane and you'll have to kill yourself, or (more optimistically), you'll be reminded of each messy bit over and over until you finally break down and clean it up.
Don't hide the mess; clean it. Otherwise it'll come back to bite you sooner or later.
It depends on what you call legacy. If by saying legacy you really mean 'code from some retired application which is so bad we'll never use it any more' it should be separated from you current code. If it is something from your current project but is written by other people or is not up to your current standards just treat it normally but flag it for re-factoring in the future in your issue tracker.