True but wouldn't the landing pages of most of these services be able to document the OS, browser, resolution, type of device(tablet vs laptop and IOS vs android) and likely a lot of other stuff.

I can narrow down a huge list to a very short list using above information along with the probes being sent out co-related to the signal strength. Timing of each probe can also be leveraged in uniquely identifying,most probes are sent in interval from each device. Those probes that come in equal intervals are likely from the same source, leveraged against signal strength you can likely identify a small crowd. To take it even further you can calculate the signal as absorbed through the store to signal congestion and possibly other metrics.

Hence the "using this tracking method" caveat. Now you have to do something much more complicated just to get less specific data. And it's a cat and mouse game: You put up a useless landing page, device makers set their browsers to require TLS for any page previously found to support it, preventing you from redirecting requests to the majority of popular sites. Or they could just detect the ARP misuse that makes captive portals work and patch that particular vulnerability, because screw captive portals entirely.

MAC collisions?

It's a 48-bit space, so you'd need around 16M people connected with random IDs to have a high chance of collision.

Even by sticking to a certain subsets of OUIs, it's still probably fine. On top of that, listening to traffic (even after picking an in-use MAC) would allow you to determine if someone else is using that address.