In a perfect world you'd do what you're describing using an EAP method like TEAP which supports in-band provisioning of credentials (like X509 certificates). Unfortunately, EAP-TEAP and its predecessor EAP-FAST haven't seen widespread implementation.
I know you were just using this as an example, but I definitely wouldn't use NFS. Even if NFS was supported on the supplicant host, manual configuration would be required. I'd say HTTP(S) is the more obvious choice for getting access to the certificates, given its widespread support, and user familiarity.
Trying to create some kind of post-authentication provisioning mechanism is going to be quite difficult. It's fairly trivial to identify an administrator logging in with credentials and assign them a VLAN which provides access only to a walled garden (where they can download their admin cert). The issue is walled gardens themselves are becoming increasingly problematic.
More websites are switching to 'secure by default' which means the initial connection attempt a user makes is likely to be over https. It's not possible to redirect/rewrite https traffic in the same way as http traffic, so it's difficult to direct users to the walled garden's landing page in a seamless way. If you did want to try a walled garden you'd need to verify it worked correctly for wired connections on your target OS(s).
Regarding using different RADIUS servers for the different EAP methods, that's not necessary. EAP provides a mechanism for method negotiation. The same EAP module in FreeRADIUS can run EAP-TTLS or EAP-TLS. If the EAP module requests EAP-TLS by default, and the supplicant has a certificate available and has EAP-TLS configured, then EAP-TLS will run, otherwise the supplicant will negotiate EAP-TTLS and and EAP-TTLS Will run instead.
Honestly though, provisioning credentials after initial authentication just seems like a nightmare for the helpdesk. Even if an administrator manages to access, download, and import their certificate, they'd need to manually reconfigure their supplicant to make use of it.
If I were implementing this I'd ditch username/password based authentication entirely, and instead use one of the dissolvable installers offered by cloudpath (now Ruckus) and others. These temporary applications can provision user certs and configure security profiles for network interfaces as part of the same operation. You'd offer the dissolvable installer via a public website, and point users to it during onboarding.
All users would have a similar onboarding experience, but administrators could be provisioned with a certificate that identified them as such, either via a special OID, or using a different intermediary CA.
