Aside from the fact that the code itself can access memory directly. What are the other implications of using the "/unsafe" compiler flag and the "fixed" keyword? Are there any knock on effects related to code signing and deployment of my .exe (my app is desktop only)?
(This isn't about whether or not I should be doing this, the why is covered in my question here)
Unsafe code is not verifiable, so you have to be aware of that. In a Full Trust environment, that's not a big deal, but if you have other environments which have a more restricted permission set, then this might impact you there.
You can put the implications into two buckets.
The first is how it affects your application environment. Using unsafe code requires that your assembly be run in a full trust environment. It's not possible to run in a restricted environment such as certain Click Once security settings. The reason being that unsafe code prevents the CLR from ensuring type safety. Click Once though with no security restrictions should not have a problem.
The second is what it means for the way you code. Using unsafe code typically involves using pointers and in particular, using them to performed advanced marshalling via PInvoke. There is nothing inherently wrong with either of these actions though. It just requires significantly more understanding of the CLR and marshalling than "safe" code does. Object pinning is a great example of knowledge you'd need to have a firm grasp on before you started using these features.
To add to Jared's reference to object pinning...
When using pointers to access memory directly in C#, you are vulnerable to the CLR moving an object around in memory at runtime. This means that your pointer may all of a sudden point at the wrong section of memory. The Fixed keyword will pin the object in memory so that this problem may be avoided.