The underlying cause of this issue has a great deal to do with the prioritisation of assembly resolution within the .NET framework. The CLR tends to favor assemblies in the GAC, giving them priority over all other accessible assemblies. Even binding redirections seem unable to work around this problem.
A crazy idea that may help to work around this could be to make sure that the version number of the assembly used by NCrunch is different to the one that is registered in the GAC.
I'm not sure how difficult it would be to rig this up in your infrastructure, but whenever NCrunch is building a project in MSBuild, it sets an MSBuild property '$(NCrunch)' = '1'. You could use this property to introduce a hack in the .proj file, overriding the MSBuild properties to change the version number in the output assembly. In this way, the assembly instrumented by NCrunch will have a different strong name to the assembly hosted within the GAC, and therefore the CLR won't pull hook up the wrong one to the test application domain.
I'm keen to hear if this fixes the problem ... if so, I might look at introducing a configuration switch that could fix this without the need for custom build hack.