Even though this reply would be probably useless for you after such a long time, perhaps someone in similar situation could use this (like I did yesterday).
My situation was almost exactly the same - NXOSv, hsrp, mac/arp issues... Though I did not use ip proxy-arp, I personally don't think the proxy-arp would provide you with the results you are looking for since proxy arp is used in environments where host A believes host B is on the same subnet (due to the subnet mask configured) although they are separated by a router into two different subnets. (Proxy ARP - Cisco )
Packet capture was a real help in this scenario. Packet capture revealed that after initial startup while trying to ping the hsrp ip, there was an arp request (logically) and the hsrp replied with default virtual mac, much like the one in the question (show.. output).
After the ping-initiating device got the reply, it used that mac in the icmp packets, packets arrived at the target device yet the device did not respond at all - hence the request timed out.
Knowing this, I performed a ping from hsrp ip (the other way around) only to find out that the hsrp device is using a different source mac address than the virtual default mac provided from the show command output. It actually used a VLAN interface mac address.
Taking a step back here to explain what is going on here. The HSRP for that VLAN is a standalone interface in the routing table with it's own mac address. It makes sense that the arp reply contained a HSRP default virtual mac for that group. Problem is, this HSRP is behind the VLAN interface (which has a different mac) so an icmp frame header is rewritten at VLAN interface, changing the source mac address to the VLAN interface (that's how routing works).
After this change, the icmp reached it's destination and the destination sent a reply to the hsrp IP with a mac address from the initial arp reply it got - the default virtual mac for that hsrp group. This is the problem we have.
The packet arrives at the VLAN interface and the looks at the L2 information first - identifies the target of this packet and finds out the target mac address is not the VLAN interface mac so it discards the packets (L3 logic)
After finding out I used a command while in interface (vlan) configuration mode ---- hsrp use-bia
The command mirrors vlan interface's mac address so these issues with discarding packets int vlan interface never happen and the ping works like magic.
Long story short, use HSRP USE-BIA command.
Hopefully you or anyone else will find this useful
I'm not 100% confident about the reply I'll give you since I wrote my former solution a long time ago.
As for your question, yes, I have been able to get them to talk with each other and HSRP between 2 NXOSv systems worked like a charm (although my solution was only a workaround to bug in the NXOSv image - the problem with MAC not being recognized, since the NXOS "to my knowledge" should have some form of forwarding table where you should see the hsrp macs and what-not - i don't remember the command but I know I've dug into troubleshooting this using real nexuses and compare the results with NXOSv and it looked like a bug in the NXOSv.. the table didnt contain all the info it should have).
I believe you're experiencing the same problem as we were. Did you try the solution from my former comment? As long as you have your configuration of trunks, etc. correct, you should be good to go with that solution I stated.