drinking bird - if it pans out that tgl's answer is correct, then ARP poisoning followed by DHCP spoofing would be the only way to get some smartphone info that I'm looking for the ARP scan portion of my utility (that I can think of at the moment - for home use), but your suggestion about pseudo OUIs is a good alternative, thanks.
Didn't quite catch the part where you were looking to update your own utility.
For devices in DNS (ones that report their hostname in the DHCPREQUEST) it should be fairly simple. You ping scan your subnet (even if devices don't respond, you'll get ARP for them) or force an ARP broadcast, then you can reverse lookup the IPs in DNS (if the device reports its hostname) and if you need it, the OUI against the public database. As far as the pseudo MACs, I don't think you'll have much luck, they are only required to use a specific second digit of the OUI to signify randomized MAC, I can't find any reference to ranges used by Apple, Android, etc. It appears to be completely random other than that second digit (which must be 2, 6, A, or E)
If the device doesn't report the hostname field when getting a DHCP lease, unless you want to add it to DNS with a reservation, you're going to be limited to just showing the vendor if the OID is known, or "randomized mac" if it isn't. The router has the benefit of being able to see more data than a scan tool will based on the fact that it can see the whole DHCP exchange plus snoop some other stuff, so it may be able to do some additional trickery that you can't.
For the icon displayed, I suspect that they first look at the DHCP exchange. Various OS's support various extra fields and announce various capabilities, and they can determine lots from that. The next step would be to look at the OUI if it is in the public database. I suppose they could also look for keywords in the hostname reported back, or snoop some traffic and look for certain patterns, but I doubt it is going to that extent. My guess is it is limited to information it can get from DHCP and/or the OUI.
For the name displayed in the client list, the priority seems to be this order (stopping when one matches):
1. Name you've manually customized in the network map list
2. Hostname you've assigned to DHCP reservation
3. Hostname reported back in DHCP response
4. Manufacturer name associated with OID
5. Raw MAC address if all else fails
Not sure how you're planning to spoof DHCP, typically the client initiates all DHCP, and if you send an unsolicited DHCPOFFER I wouldn't think you'd get a response, but never tried. If you're going to poison the ARP to try and force the client to send a DISCOVER and REQUEST and snoop those broadcasts, I guess that could work, since you won't actually be replying, just watching. But keep in mind that DHCP renewals are unicast which you won't see, so the client has to be forced to start the process from scratch (release and renew essentially) which will interrupt their traffic when you scan. If you are able to get the full DHCPREQUEST packet then you should be able to see a good amount of info on the device.