How about just releasing the code as open source ;-)
Heck, not everything should be protected and if you DO need that kind of protection you can always go the more conventional way of writing only that specific part (usually an algorithm) in native code.
.NET is REALLY good (performance wise) in P/Invoke.
This doesn't seem to be all that complex, mostly you just need to hook into the AssemblyResolve event and store the encrypted assembly as a resource in the main assembly. It gets interesting when you try to unencrypt it, because then you have to deal with securing the key.
I suppose that it can be done via a web service or something like this, but performance will suffer if it is done remotedly.
The interesting question is where they put their keys.
The "JIT decryption" pattern has been around for a long time, and became commonplace in the mid-90s when viruses self-decrypted their payloads in order to dupe the weaker signature-based scanners.
The problem with this type of protection is that the weakest link is in the interface between it and the platform (in this case the CLR). Once their algorithm is discovered, it becomes easy to insert a layer in between (think 'rootkit for CLR') which can access the unprotected code. So in theory it does discourage "casual decompilation", but everyone knows that in X months ( 1 < X < 4) the ripper with be up on IRC/Kazaa...
After some investigation, looks like this is not encryption/decryption technology. This is kind of partial pre-compilation. The pre-compiled code is executed by what they call "SVM" - some Virtual Machine. The idea is that pre-compiled code does not need .NET metadata anymore, and it has a custom format, which also may vary. So decompilation of such code is impossible, but clearly should be some performance impact. The SVM itself runs on top of CLR, so it is not like compilation to native, the code is still managed. This is good, especially for code security support.