Yes and no.
On a practical level, it can be implemented and could enjoy the benefits of the greater amount of bandwidth 802.11 gives you over Bluetooth. There are a number of issues however:
1. There are no serious, widely used, obvious standardized music protocols for connecting audio applications to headphones over an internet connection. I'm not saying there aren't protocols in existence that do parts of the job, GNU/Linux's esound is one example of a pure "remote speaker" protocol, but that only covers the "Send sound to a device already on the network with an already known IP address" part of the system. It doesn't cover establishing a network connection for the headphones or advertising the audio player service to the audio originator.
Without a standardized way to take headphones out of a box, turn it on, tell your audio player to "Scan for headphones", select the new set, and "pair" them, all devices will be proprietary and refuse to interoperate with one another. In the mean time, I doubt any serious efforts are being made to make this work given Bluetooth already does it.
2. The power consumption of 802.11 is fairly high. Nintendo is able to get away with it on the DS by throttling down the 'b' variant to its slowest supported speed, barely 1Mbps. This speed is too little for uncompressed music, and compressed music requires a substantial amount of processing which makes headphones far more expensive and complex, also adding to the energy requirements of the device.
In practice, Bluetooth solves these problems by already doing it. The downside of BT is that it does have the compression issues, but on the other hand, as the only advantage of 802.11 here would be the improved bandwidth, which can only be achieved at the cost of creating new protocols and sucking batteries, it's a no-win situation.
In the end, I'm hoping Apple will eventually start to support Bluetooth in earnest. One hopes the iPhone will work as a wedge to get that kind of support into their audio devices in general.