Security is worse and goes beyond a simple confidentiality issue.
As you stated it is indeed "subject to casual eavesdropping", but as you also noticed the legitimate user is "allowed to connect to the Internet through MAC address filtering".
An attacker can change his own MAC address to share the same one as the legitimate user. This creates a MAC address conflict, but in practice this just results in some warning messages appended to some system log file that end-users never check anyway. Connection is maintained and works for both parties simultaneously (as they share the same collision domain).
From now on, not only the attacker can eavesdrop legitimate user's data but the attacker can now impersonate him in the eyes of the hotspot (and the infrastructure and provider behind it). The attacker is usually also able to keep the access open any arbitrary time after that the legitimate user went away (this requires the attacker to simulate regular activity all along, either any random activity or simulate a certain "authentication" web page refresh, but this is easily automatable).
Most, if not all unencrypted open WiFi accesses relying on a portal suffer from such issues: hostel, paid WiFi access, public hotspot services that some ISPs push to their end-user to share their WiFi with other subscribers, etc.
From there, you have two main ways to secure this:
Either stay in the upper network layers: provide a VPN client application to the user (don't necessarily call this a VPN, from a commercial point-of-view anything will do: "WiFi-Access", etc.). Instead of using a web page the user will use its client software to authenticate itself and "open" the WiFi access (in practice the unencrypted WiFi provides access to a VPN server, itself providing access to the Internet to authenticated clients).
Or you fix the problem in the lower layers: provide end-user either a PSK "WiFi password" (hostels case for instance), or instead of providing them an VPN client application provide them certificates that will be used to connect to your hotspots (ISPs case for instance). From there a more secure channel will be established between the end-user and the acces-point, allowing the user to securely authenticate to the hotspot's captive page.
There is no way here to, as you suggested, create a security token at an higher layer (the application layer, here the browser) to use it to secure a lower layer (the data link layer, here the WiFi connection). You implement security either at one or the other layer.
