I hear you man, I'm a C programmer myself and being so familiar with the syntax I have repeatedly tried and failed to learn C++, it just seems completely unnatural. For me, I learned assembly at a young age so growing up with it and with low level concepts it seems natural. eAX is actually a register. You see AX is a register which can hold 16 bits (in 16 bit assembly). EAX can hold 32 bits (in 32 bit assembly) and RAX is the 64 bit version. So if you're decompiling on a 32 bit machine you'll see instructions pointing to eax.
As for what a register actually is, think of it as a form of memory slot, in which you can store values and retrieve them but much much faster than doing so from the computer's memory (with pointers and such). This is where the stack comes in
See here for a nice explanation:
http://www.friedspace.com/assembly/cpuregs1.php
In malware, you do see more complicated instructions but of course, some instructions are the same from malware to malware. Here's a simple chunk of assembly which checks to see if we're being debugged by OllyDbg.
Code:
mov eax, fs:[30h]
movzx eax, byte ptr[eax+0x2]
or al,al
jz payload_
jmp killprocess_
So in this example, we find the segment 30h which contains something called the 'PEB' and we movzx the byte at 0x2 of segment 30h into eax (this is now a zero extended value which gives us access to the AL segment of it). The next instruction checks to see if AL is 0 (or Al,AL), and if it is (JZ - Jump if Zero), we execute our payload, otherwise we skip over and JMP to our killprocess function which either idles out or does kills our process and melts or something, whatever.
But those are the kind of code segments that you will gradually learn to identify. Of course I can't look through a program in a debugger and tell you exactly how it works just from the assembly code, but I can dive in, analyse it piece by piece and work out what it's doing and what states or values trigger that behaviour, and this is how you build a picture of the program (looking at the stack/heap/registers etc of course too).
As for breaking out of VM, yes it is possible. Malware it much more likely to break out of a sandbox than a virtual machine, and the reality is quite overhyped I'm afraid but yes malware can break out in rare cases. For example, if you mount a physical USB drive in your virtual machine (for example to transfer files), the malware gets access to that, and when you dismount and use it in your normal computer, there is a copy which has been brought out of the machine. There are other ways but they are much less common and I haven't encountered them in the wild myself (in realistic usage), I'm sure another member here will explain those before me
Hope that helps a bit