As you've presented it, no, VLANs are not going to help you much.
What it will help you with is not propagating broadcasts and multicasts to every host on the (non-VLAN'd) network.
When a host receives a broadcast, it *must* look at it, if the broadcast is not pertinent to that machine, you've wasted processing cycles, and (at the least) somewhat congested the incoming stack for that device.
For as much as I hate to use it, the water & pipe analogy still probably works the best:
If you have one hose (the path from one device to another through the network), and you have a valve that can feed four different colors of water into the hose (either direction ... the colors equate to VLAN traffic), and one source is feeding purple water through the hose at the hose's capacity ... then there is no room for the other colors of water to pass ... .in fact, the addition of the colors (VLAN tags in a trunk) REDUCE (a little) the amount of purple water that can pass, and reduce (a little) the overall capacity (regardless of the color).
Network management goes beyond the infrastructure. You can create VLAN segments on a switch ... that will keep the heavy traffic isolated to a portion of the switch (inside the switch, assuming a non-blocking fabric).
At some point, you'll need to aggregate the traffic and move it to some other portion of the network. At that point, you must decide to either limit the traffic somehow, or present a path that is equal to, or greater than, the amount of traffic that must use that path.
Other design issues, like many-to-one scenarios, require you to pay attention to where the traffic comes from (and in what volumes), and where the traffic is going (and in what volumes).
In some cases, you may decide to feed the users at ten megabit, and trunk to the core at 100 (or 100 & 1000 ... whatever the scale).
In a many-to-one scenario, about the worst thing you can do is have 23 ports @ 100Mb feeding the only egress port which is also running at 100Mbit (a 23:1 oversubscription). With any normal traffic flows, this switch is going to start buffering ... extra latency, occasionally-to-frequently causing frame / packet drop from excessive delay (and / or messing up your VoIP, Video, database apps .....).
For the scenario you've presented, you might want to look at partitioning the broadcast domain with VLANs, but use multiple trunks / paths to divide the VLAN's traffic (i.e., VLAN 100 goes on the trunk at fa0/1, VLAN 200 goes out on the trunk on fa0/2...) to different distribution / core switches. Send the high-traffic out on a trunk with another lower traffic VLAN, and pass several ~medium-level flows out another trunk.
Monitor and measure the flows (baseline!), develop a plan, implement the plan, monitor & measure, adjust .... then repeat.
Blind implementation is a bad thing; don't always assume that whatever action you've taken is automatically going to improve the system. Measure before, plan, implement, measure again after under similar circumstances, then compare & tweak as necessary.
Parson the ramble ... .it's been a long week.
Good Luck
Scott
