A couple thoughts before you write off using the Full version of R2. I was a die-hard fan of Server Core (Still am actually) but after a year of running Hyper-V cluster on Server Core, I have some new thoughts on Core vs Full.
With R2, we now have Cluster Shared Volumes and Live Migration so you can move VM's between nodes without any downtime. It's essentially the equivalent of V-Motion from VMWare. Now that I don't have to pause/resume VM's to fail them over, the patching of physical nodes is not such a big deal anymore.
Secondly, as much as I love command lines, half of my ops do not like them as much. I ended up being the top resource because of the steep learning curve when all you have to work with is the command line. So, depending on the skill of the group that will be managing the servers day to day, this might be a factor.
Also, for networking, if you ever get into teaming NIC's, good luck doing that in Server Core. To configure teaming on Intel and Broadcom, you'll need to use their software that only installs on Full.
Considering the HA you get with live migration and the ease of managemmet with the GUI for our operations team, I am encouraing our team to move to the Full version of Server 2008 R2.
Minor Update
After reading this whitepaper, it looks like CSV is recommended but not required for Live Migration. In my earlier post, I had inferred that you needed CSV for Live Migration. This is not necessarily the case.
If the VMs can't ping even between themselves, then something is definitely broken here, and it's not related to the RRAS service running on the host; regardless of their default gateway's behaviour, machines placed on the same network and with proper IP configuration should be able to talk at least between themselves.
Did you try disabling Windows Firewall on the guests?
Also, as per Greg Askew's suggestion, I'd try removing RRAS on the host; maybe it's messing up something with Hyper-V networking.
Best Answer
Since both NICs are on the same switch & VLAN, start looking at Layer 2. What occurs on either ARP tables as the result of a simple "ping" from either direction? Does the corresponding MAC show up on the opposite end's ARP table? If the ARP entries are correct, then move up to Layer 3 by checking for IP level filters as the next stop/step up the OSI model (heading towards the Event Logs as needed).