So this is going to be a bit of a long winded answer. Controllers count against the device count in a 'per controller' fashion (4 controllers = 4 devices counted against the MM count) but the per controller limit is not the same as the devices (you'll see on the data sheet there is a different maximum controllers versus maximum APs). Access Points count against the per-device count, as does every single switch and switch stack* using Dynamic Segmentation (DS) against one or more of your MCs under the MM. These device counts (controller and AP) are fixed and a hard limit. if you have an MM-VA-500, it can do a MAXIMUM of 500 devices (controllers, APs, and switches/switch stacks in DS) with a specific max of up to 50 controllers. If you needed to terminate 100 controllers against the MM, you need an MM-VA-1K. **MMs in redundancy do not count against any device deprecations** so ify ou have 2 MMs (active/standby) or even 4, because only one is active at any time, it's not counted against the device limit.
In your example, 8 MCs, 470 APs, and 45 edge switches/switch stacks doing DS would mean there are 523 devices to terminate against your MM. If you are doing VIRTUAL MM, then correct you buy the MM-VA-500+MM-VA-50, and you provision on your hypervisor the resources for an MM-VA-1K. This gives the VMM the resources to support more than 500, but you just stack the liceses to enabled 550 (just like if you wanted to purchase a 7280 and only terminate 10 APs on it).
Number of clients noted on the DS is what QA tests to, but it *IS NOT* a hard limit. So you COULD push the number of clients above the noted number on the DS, but should there be issues and TAC determines it's a load issue, you would be asked to increase the resources on your VMM. So say in your above case with 470 APs, you provision a MM-VA-1K which QA supports a max of up to 10k clients. However, let's say you average 50 clients concurrent per AP, which would be 23,500 clients. You would then want to provision your VMM as an MC-VA-5K (giving it the CPUs, RAM, and Disk to support a VMM 5K), it would use your 550 MM-VA licenses for your 523 devices, and be scaled up with CPU/RAM/Disk to support up to 50k clients. And these clients will include wireless clients, as well as any client in User-Based Tunneling (UBT) or Port-Based Tunneling (PBT) when the edge switches are doing DS, or any wired client marked as untrusted on a wired port of a controller. Ala any device, wired or wireless, that shows up in the user table of the controller will count against the client count of the MC they terminate on, as well as the MM that manages the MCs. 5k wireless+wired clients on each MC, if the MM has four of those MCs, that's 20k users that show up in the MM user table. This count also does NOT include the user standby tunnels, only the active user tunnels.
This is one reason why hardware MMs, while they have their place, are not as flexible, because to go from a MM-HW-500, to a 1K to a 5K requires 3 different appliances. For a VMM, you just re-size the MM using the hypervisor and the migration happens in the background as part of the growth process.
Regarding DS from your switches, you can think of edge switches just like an AP in terms of consumption of licenses, and they will deprecate an AP/PEF/RFP license the exact same way. Also, each switch supports up to 32 tunnels (either PBT or UBT) which helps constrain the tunnel count and prevent over-running the controller from a tunnel max perspective. But be forwarned, if you were to run all your APs with 16 BSSIDs, and then max out the UBT/PBT tunnel count on each edge switch, and then under provision your controller to the AP max, you could exceed the tunnel count of a controller. So be congniscant or max tunnels and the tunnel limitation of your controllers (or just don't skimp on the controller and overbuild at the front so you don't risk exceeding later). Tunnel counts are on the MC data sheets as well. Note tunnels do not terminate on MM, for the MM it's just a matter of device counts as noted above.