Trash, I'm pretty sure you're conflating USB peripheral vs. host devices again. (Granted, I'm having trouble following things again.) To really grossly oversimplify it, it's a lot easier to make a USB peripheral than a USB host, and anything that converted a USB keyboard and/or mouse to ADB would be a *host* while your little TTL->USB toy is a *peripheral* and there's no way to turn it around to be a host.
There are some small microcontrollers that are fast enough to do USB Host in software; example:
https://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html
It implements enough of a low-speed USB 2.0 hub on an AVR32 to drive a mouse and convert its output to serial. There are also "prefab" USB host chips that can be used to offload the entire USB protocol stack into a "black box":
http://www.ftdichip.com/Products/ICs/VNC1L.htm
Thus if you really wanted to use USB devices instead of PS/2 if you certainly *could* use them without an impossible amount of effort. Really though, if you're talking about actually *developing* something I'd strongly suggest using PS/2 devices for the initial version simply because PS/2 is basically known backwards and forwards, there's tons of driver code you can steal, and it's simple from an electrical and timing standpoint. It's the ADB side you need to figure out, why pile on complexity on the front end when it's the back end you're worried about?
There are some small microcontrollers that are fast enough to do USB Host in software; example:
https://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html
It implements enough of a low-speed USB 2.0 hub on an AVR32 to drive a mouse and convert its output to serial. There are also "prefab" USB host chips that can be used to offload the entire USB protocol stack into a "black box":
http://www.ftdichip.com/Products/ICs/VNC1L.htm
Thus if you really wanted to use USB devices instead of PS/2 if you certainly *could* use them without an impossible amount of effort. Really though, if you're talking about actually *developing* something I'd strongly suggest using PS/2 devices for the initial version simply because PS/2 is basically known backwards and forwards, there's tons of driver code you can steal, and it's simple from an electrical and timing standpoint. It's the ADB side you need to figure out, why pile on complexity on the front end when it's the back end you're worried about?