"most innocent looking snippet of code that in fact plants a virus"
Well, it's not a virus, but a fork bomb is generally very short. You could obfuscate it by writing the loop condition so that it looks like it's supposed to just run once if there's no error, but is actually designed to always loop infinitely (like the third example in the recent article here).
It's hard to disguise all bits of a virus since you need to include file I/O and that's going to look suspicious in many bits of code. Still, there are some things you could try...
1. companion viruses
It seems that these are still possible. Make a hidden .COM file corresponding to an existing .EXE or whatever. The .COM is executed when both extensions are present. Alternatively, get the user to set %PATHEXT (tell them it's needed for your program to work due to filename conflicts)
If the compiler accepts Unicode characters, use the fact that some characters look the same even though they're different code points. Put an innocuous version of a routine in an obvious place at the top of a file and hide the malicious version (that's actually called) somewhere more out of the way.
3. Deliberately smash the stack
If the program looks like it should legitimately be using XOR on strings (like in a random number generator, encryption routine or similar) then introduce a bug that overwrites the call stack and executes a bit of machine code that's already embedded in the code (in obfuscated form, requiring the xor to decrypt it).
It's a lot easier to introduce deliberate bugs that can be exploited later (by specially-crafted input) than it is to hide a complex program inside another.