ESX/ESXi can be heavily tweaked (using a whole raft of 'advanced settings' and VM CPU-bit settings) to allow for vmotion between AMD and Intel - the issue is that it causes a bigger problem that it fixes.
The reason ESX/ESXi don't allow it 'out of the box' is that different CPU families offer different CPU capabilities which in ESX/ESXi's case are passed through to the VMs to allow them to be used properly. Now if a VM on a modern Intel CPU thinks it can use for instance SSE4.2 commands and is then vMotioned to a CPU that doesn't support that capabilities, well you get a major crash.
The way around this is to set a 'highest common denominator' baseline, i.e. in a cluster you choose the least capable CPU available and only expose its functions to the VMs, ignoring the functions available to newer, more capable CPUs - thus allowing VMs to move around.
If you manually 'prune' all of the capability differences between an AMD and Intel CPU to find an absolute baseline CPU specification then you will of course be able to move VMs between these chips without risk of crashing, I don't know KVM at all sorry but I'll assume that this is how it allows this. The downside of this is that you're not allowing your VMs to use any of the more advanced CPU functions available to modern chips, so they may move yes but they'll be slower and less functional.
I hope this helps you understand why this isn't a commonly used, or in my opinion a wise, path to take.