Rubeck, seems like you earned the points, no more issues reported with vMotion, thank you! 
However this doesn't tell us the root cause of the issue and it seems like a bug on the VMWare side.
Other thoughts:
One of the things that is going on is that the VMotion interface and service console share a tcp stack if they are in the same vswitch, which they never used to share in pre-5 if I recall, even if they were in the same vswitch.
We think, that, coupled with using the same address space, it is simply allowing the service console to go ahead and respond to the V motion traffic.
Our guess is that changing the subnet on the V motion traffic is what allows the traffic to only be responded to by the V motion interface on that box.
We think that moving the service console into another vswitch on each of the server hosts would do the trick without having to manage two different subnets as that would have the effect of putting each of those service consoles and the Vmotion interfaces in different TCP stacks.
More testing will follow.
Anyway, for now it works.
Thanks everyone!