Personally, I would choose to disbelieve that everyone will actually migrate by the expected date. Even if I'm confident that it's going to happen, I don't want to create extra work for anyone, or stop them working, in the event that I'm wrong.
If nothing else, builds should be reproducible. What if, in December, you realise that you need to reproduce a build from October? You can't (at least, not without bodging the clock on the build machine), because it won't compile any more.
So, I'd do this:
support2005.h
-------------
// empty file
source file
-----------
#include "support2005.h"
#if _MSC_VER >= 1600
// clean version of the source code
#else
// less clean version
// of the source code
// requiring multiple lines of code
// and requiring some dirty static_casts
#endif
Once everyone has VS 2010, change support2005.h to contain #error "Remove Visual Studio 2005 compatibility code from this file".
Actually I personally wouldn't check that change in, since it will prevent anyone from doing any work until VS 2005 support is removed. Is removing dead code really the highest priority task your company might possibly have on the morning of 1st November? And does it require all hands on deck to do that? Rather, I would check out, delete the file, do a full build, keep removing compatibility code until everything build again, and check the whole thing in as, "remove VS 2005 support".
You say you're worried you might forget, but if you do, so what? The dead code isn't hurting anyone. You'll remember it the next time you look at any of those files, or the next time you see "support2005.h" in a file list, header dependency graph, etc. So it's not "making the source code unreadable long-term", because long-term anyone who sees it can just ignore or delete it. If you have any kind of issue-tracking software, you could find the first milestone targetted after 2010-11-01, and attach a task to it, "remove VS 2005 support, and get rid of support2005.h", with a note that this is currently blocked by developers still using VS 2005.
If you really want 2010-11-01 to be a hard deadline, after which the code breaks, then just stay up until midnight on Halloween, and check in the breaking change then. It doesn't actually break the code, as you requested, but it does break anyone who refreshes from source control, and hence presumably it breaks the build. Most importantly, it's very easily reversible, or can be suppressed locally, if it turns out to stop someone getting work done.