If you're developing in 64-bit for a 64-bit OS, the build box needs to be 64-bit. You can build 32-bit stuff on a 64-bit OS, but you can't go the other way around.
You can install 32-bit Isolator on a 64-bit box - we're doing that right now - but you can't have both 64- and 32-bit running at the same time.
The whole "bitness" aspect of things is something we're struggling with right now and I don't have a good answer for. We are working on a product that will target both 64- and 32-bit OS. Unfortunately, the TypeMockRegister task doesn't take a parameter saying which bitness to deploy, so we can't easily say "deploy the 32-bit version when the 32-bit build runs, undeploy that, then deploy the 64-bit version when the 64-bit build runs." The problem, as you noticed, being that you'd have to change the .csproj assembly references on the fly.
You could probably do some crazy fancy on-the-fly switcheroo by passing customized parameters into the "MSBuild" task that builds the .sln or .csproj file(s), but I've not gone down that path and it seems a little convoluted. You could also possibly do some file copy/replacement to switch the Isolator .dll files that sit in the same folder as the build task assembly so the appropriate version gets registered at the right time, but again, I've not gone down that path, either, so I don't know if you'll run into trouble.
The 64-bit vs. 32-bit problem is similar to the side-by-side installation problem (how do you have two different versions of Isolator installed at the same time?). I haven't seen a good solution for either of them.