I would personally stick with the comments in the code. You could always put regions around them and collapse them if you have to. By keeping them directly with the code, you get the benefits of Intellisense filling in parameter names, etc. I know it can be a bit of a distraction, but I find it the best way to go. It also means that when reading the code you can check what you've documented it to do very easily.
An alternative might be to keep the comments in a separate file (per source file) and have a pre-build step which merged the files together in some temporary area, which is where you'd build from. Your XML comments would need to have some identifier before them to make it clear which member they described, and you'd need to write the tool to do the merging. You could make this simpler by including a single comment before each method, e.g.
// doccomment:MyMethod(asd)
The bit after doccomment would be irrelevant, just used as a token, but I'm sure you could come up with your own convention to keep it in sync with the other file, which would look like this:
// doccomment:MyMethod(asd)
/// <summary>
/// This method squurbles the frobdicator.
/// </summary>
You'd then just replace the single line comment with the identified text in the comment file.
This does all sound like a real burden though - I would think long and hard about how painful having the comments in the code really is.