Edit 2:
As you mentioned...
ip route 10.1.0.0 255.255.0.0 iface0
Forces the Brocade to proxy-arp for every destination in 10.1.0.0/16 as if it was directly connected to iface0.
I can't respond about Brocade's ARP cache implementation, but I would simply point out the easy solution to your problem... configure your route differently:
ip route 10.1.0.0 255.255.0.0 CiscoNextHopIP
By doing this, you prevent the Brocade from ARP-ing for all of 10.1.0.0/16 (note, you might need to renumber the link between R1 and R2 to be outside 10.1.0.0/16, depending on Brocade's implementation of things).
Original answer:
I expect that in most, or even all, implementations, there is a hard limit on the capacity of the ARP table.
Cisco IOS CPU routers are only limited by the amount of DRAM in the router, but that is typically not going to be a limiting factor. Some switches (like Catalyst 6500) have a hard limitation on the adjacency table (which is correlated to the ARP table); Sup2T has 1 Million adjacencies.
So, what happens when the ARP cache is full and a packet is offered with a destination (or next-hop) that isn't cached?
Cisco IOS CPU routers don't run out of space in the ARP table, because those ARPs are stored in DRAM. Let's assume you're talking about Sup2T. Think of it like this, suppose you had a Cat6500 + Sup2T and you configured all Vlans possible, technically that is
4094 total Vlans - Vlan1002 - Vlan1003 - Vlan1004 - Vlan1005 = 4090 Vlans
Assume you make each Vlan a /24 (so that's 252 possible ARPs), and you pack every Vlan full... that is 1 Million ARP entries.
4094 * 252 = 1,030,680 ARP Entries
Every one of those ARPs would consume a certain amount of memory in the ARP table itself, plus the IOS adjacency table. I dont know what it is, but let's say the total ARP overhead is 10 Bytes...
That means you have now consumed 10MB for ARP overhead; it still isn't very much space... if you were that low on memory, you would see something like %SYS-2-MALLOCFAIL.
With that many ARPs and a four hour ARP timeout, you would have to service almost 70 ARPs per second on average; it's more likely that the maintenance on 1 million ARP entries would drain the CPU of the router (potentially CPUHOG messages).
At this point, you could start bouncing routing protocol adjacencies and have IPs that are just unreachable because the router CPU was too busy to ARP for the IP.
Switches without MLD or IGMP snooping will treat multicast and broadcast (if there were broadcast in IPv6) the same -- namely, they would flood the packets out all ports.
But the second half of your statement,
"and therefore negate the benefits of multicast"
doesn't follow. The advantages of multicast are not for the switch. They are for the end hosts.
End hosts can process multicast more efficiently than broadcast packets. The network interface card (NIC) on most hosts can be set to accept specific multicast addresses and reject all others, just as they do with unicast packets. So unwanted multicast traffic is ignored by the NIC as well as unwanted unicast traffic. But when the host receives a broadcast packet, it must accept it and send it to the CPU to process, even if it is not important to this host. In a network with lots of broadcast traffic, hosts are continually interrupted to process the broadcasts, even though they care about very few of them.
Multicast solves this problem by "delegating" the task of selecting important packets to the NIC hardware. Only packets directly addressed to the host are sent to the CPU for processing.
Best Answer
As Michael Hampton points out, ND does a great deal more than IPv4 ARP, but I will answer from the perspective of simply resolving a layer-2 address from a layer-3 address (ARP function).
ARP broadcasts requests to every host on the LAN, and that interrupts every host on the LAN to inspect and process the request to see if it is for them.
IPv6 has eliminated broadcast (a good thing). Instead, each interface must subscribe to a solicited-node multicast group for each IPv6 address assigned to the interface (each IPv6 interface will probably have at least two IPv6 addresses, and maybe more) based on the addresses assigned to the interface. When ND tries to perform an "ARP" function, it sends the request to the solicited-node multicast address (based on the IPv6 address to resolve). That will probably interrupt only the target host (far fewer hosts than IPv4 ARP).