No. You still need the CA cert to be present on each supplicant machine, and trusted by each supplicant.
Even if you present a certificate signed by a pre-installed CA, most supplicants require the user to explicitly trust that CA before accepting the certificate.
802.1X, 802.11i and no EAP standards that i'm aware of, specify a relationship between the CN of the certificate presented to the supplicant, and the SSID of the network, so the CN can be anything you want, with the caveat that some windows supplicants do not accept wildcard certs (apparently, i've never verified this personally).
The same certificate may be presented by multiple RADIUS servers in the same cluster, though if you use a front end load balancer, it must ensure that all packets in the EAP conversation go to the backend server. Because of the possibility that many users will configure an anonymous outer identity, this is best done using the Calling-Station-ID attribute in the RADIUS packet.
For added security, if you're using a pre-installed, public, root CA, it's best if you configure the supplicant to verify the CN in the certificate matches a preset value. This prevents spoofing attacks using other certificates signed by the same public root CA.
Though, because of the possibility of misconfigured supplicants, it's best practice to avoid public root CAs, roll your own CA, distribute this to users of the network in an importable network profile, and in this profile enable CN verification.
There are multiple tools which can generate these profiles for different platforms/supplicants. If you're planning on deploying eduroam, you may want to check out Eduroam CAT.
There's also Cloudpath's xpressconnect which is a dissolvable installer, which in addition to installing the profiles, may act as a temporary NAC agent, verifying patch levels and driver versions.