I think the major issue is that Wi-Fi is probably the wrong technology for the job, if you're really talking about 3,000 clients in a small area like a ballroom. For fewer clients spread over a large space, I think it's feasible.
Covering a ballroom with potentially thousands of clients is going to be a stretch for Wi-Fi, assuming that the clients are actually using the network. You've only got 3 non-overlapping channels (in the US), and I've never seen an access point (AP) reasonably support more than 50 clients effectively. You're going to end up with a lot of access points sitting on the same channel and a lot of contention for the air. That's a lot of client devices to have in a small area.
If you could rig some kind of highly directional antennas and radio power was clamped down to target small numbers of clients you might make this better. For a temporary event like a conference, the level of obsessive care that such a site survey would require would, I'd imagine, be unreasonably expensive.
Assuming you're covering a lower client density than 3,000 clients in a single open-air space, you'd want to space APs with coverage zones sized to handle a significant fraction of the possible number of clients that AP can support (by tweaking radio power / antennas), and you'll want to try and keep adjacent APs on non-overlapping channels. The more APs the better, and don't overload the APs with too many clients. (Tweaking radio power / antennas to make coverage zones seems non-intuitive to anybody who hasn't tried to scale Wi-Fi to handle a large number of clients in a small physical area.)
From a layer 2 broadcast perspective, it would make sense to broadcast multiple SSIDs and back-end them into different VLANs / IP subnets. That would depend on the number of client devices and the character of the traffic. Personally, I wouldn't put more than about 500 devices in a single layer 2 broadcast domain on a corporate LAN. I can only imagine that a conference Wi-Fi network would be worse.
DHCP should be a no-brainer, though redundancy is a concern. I'd probably use the ISC dhcpd and work out a failover arrangement to a second server. I think I'd be on the lookout for rogue DHCP servers, too. On wired Ethernet you could easily disable the ports that rogue DHCP servers show up on. For wireless Ethernet, it's a little more problematic. Anybody know if there are APs that support blocking mobile units based on MAC address? (That doesn't help if the rogue DHCP server spoofs its MAC once detected, but it's a start...)
Obviously, the firewall / edge router should be able to handle the number of NAT table entries that such a number of clients might generate. A consumer toy NAT router isn't going to handle it. A redundant router protocol (HSRP, VRRP, etc) and multiple edge router devices are going to be a necessity to prevent a single point of failure from ruining the whole show.
As for bandwidth contention on the backhaul, you could throttle client bandwidth to the Internet. That should also limit the overall contention on the air, to some extent.
I'd throw something like Squid Cache in place as a transparent proxy for HTTP traffic. That's going to help with utilization of the backhaul. Your HTTP proxy cache shouldn't be a point of failure, so you'll need infrastructure to monitor the cache's health and, if it fails, route around it.
I don't have the energy to fire up a spreadsheet and look at the economics of a bunch of small Ethernet switches and patch cables strewn about, but the more that I read, the more that it sounds like wired Ethernet would be a great way to pull off decent connectivity. There would be, no doubt, major effort needed to run the Ethernet cables and power the switches, but it provides a much more manageable network infrastructure, more reliable bandwidth, and requires a lot less obsessive tweaking than wireless. You could get away with using low-end gear for the edge switches, too, since 100 Mbps service would plenty for the purposes of accessing the Internet.
Cisco has a little 8 port switch that draws its power from PoE-- the Catalyst 2960PD-8TT-L. That'd be sweet for this application-- putting something like that on each table, drawing its power from a larger PoE-capable switch. I'm guessing that those are pretty expensive for this application, but I'm guessing that there's a "downmarket" option that's not as pricey available from somebody. (Searching for switches powered by PoE seems to be fairly difficult with Gooogle...)
Intel has a 2006-era paper re: providing Wi-Fi access at conferences. Looking at their numbers, they had 50 clients on a single AP at one point, and a peak client load under 100 clients total. Those seem like pretty small numbers compared to what you're talking about, and in 2006 everybody wasn't carrying around iPhones, etc.