I've just seen a similar issue to this where some lambda expressions are used within views which leads to a corruption of the .Net dll when compiled on a 64 bit system. It results in the same exception you are seeing, and certainly sounds like a likely candidate.
Apologies if this seems a little vague, as we haven't fully resolved this and are still looking into it, although I'll be sure to update here when we have a resolution.
The trail that makes us believe this is an actual corrupt dll, is that if you view your compiled view dll in ildasm.exe, and examine the actual method call involving the lamda, you get a "[SIGNATURE ENDED PREMATURELY]" error shown in ildasm. RedGate's reflector, however, crashes when trying to expand the method.
In our case, the ildasm looks like this:
IL_029f: call class [System.Core]System.Linq.Expressions.Expression`1<!!0> [System.Core]System.Linq.Expressions.Expression::Lambda<class [System.Core]System.Func`2<class [MyCode.Authentication.Admin.Mvc]MyCode.Authentication.Admin.Mvc.Dto.InternalUserDto,object>>(class [System.Core]System.Linq.Expressions.Expression, class [System.Core]System.Linq.Expressions.ParameterExpression[])
IL_02a4: call class [System.Web.Mvc]System.Web.Mvc.HtmlHelper [MyCode.Extensions]MyCode.Extensions.System.Web.Mvc.HtmlHelperInputExtensions::CheckBox<[2]>(class [System.Core]System.Linq.Expressions.Expression`1<class [System.Core]System.Func`2<class [MyCode.Extensions]'type parameter'.T,object>> [SIGNATURE ENDED PREMATURELY])
We've noticed this is a 64 bit issue only. We are about to investigate whether this issue still occurs on .Net 4.0. I'll update here when we know.
We are also in the process of seeing if this has been raised as a bug with Microsoft. Again, I'll update here when we know.
[EDIT: having now got to the root cause of the problem]
I thought I'd come back and update this answer.
For us, it turned out that this wasn't a compiler issue at all, but an issue with aspnet_merge. In short, on our 64 bit build boxes, we were using an older, out-of-date copy of aspnet_merge (accidentally) that appeared to work but resulted in these corrupt dlls (in exactly the way you describe). A path had been changed, so our web deployment project was using this wrong version.
Updating the path to aspnet_merge version 3.5 or higher, fixed the problem.
We thought this was a 64bit issue originally because our build boxes were the only 64 bit environment we compiled on (all our dev workstations are 32 bit), and the only one to have this problem. However, the "bitness" was a red herring!
Hope this helps you solve your problem.