Yes, that is roughly 781 - 825 or so Kbps (including 28 bytes for overhead per UDP packet too), looks good.
This assumes that 100 byte packet contains all the information for all the updates for every player for that second. In other words, that assumes every second, at most 10 players out of the 1000 will send a 10 byte message, or 5 players will send a 20 byte message etc. If that is what you have in mind, then yes, that will come to 781-825 Kbps.
I think your overall question is whether to design the architecture as "peer-to-peer", or "client-server".
In peer-to-peer, there is no centralized server. Each client, when sending a new text message to the chart room, fires off a message to the 999 other players. In this instance, they aren't receiving 1 packet containing a summarized list of all messages from everyone else, they instead receive 1 packet for each individual message.
So they might get messages like this:
(username | room # | message )
"David|3|Hey there!" - 18 bytes + 28 bytes of overhead = 46 byte UDP packet
"Sonya|7|brb" - 11 bytes + 28 bytes of overhead = 39 byte UDP packet
The overhead of 28 bytes per packet really starts adding up, since each individual text message (I assume?) is on average so small. So let's take an average of 10 messages per second altogether, of each being 10 bytes (which I sort of arbitrarily came up with). In that case you are looking at 38 bytes per packet, with 10 packets per second. That is 388 bytes per second, or about 3,100 Kbps (3 Mbps).
In terms of can a typical client handle it? I'm at a coffeeshop now and speedtest.net gives me 17 Mbps download and 4 Mbps upload, but it is a nice connection. I'm seen several places that have a tenth of that. I think if your requirement is 3 Mbps that is fine for broadband users and most coffeeshops etc. But, it will fail for 3G wireless users and places with relatively poor connections.
With a client/server model, the network requirements are lower (it uses less bandwidth), because it is more efficient in terms of combining the message. Also, the clients have far less upload network usage. They just upload to a single IP (the server), instead of all the other clients. So with the server model, it is much easier for you to support a larger variety of clients since you are looking at only about 1 Mbps instead of 3 Mbps, since you are sending less overhead (the single packet combines multiple text messages into 1).
Keep in mind you will probably need some kind of client/server model regardless. That is because you will need some sort of lobby so that clients know all the IP/ports of all the other clients currently connected. The networking requirements to handle that lobby (getting a list of all IP/ports, users entering and leaving chat etc) might take nearly as much as the main chat server anyways, so you may as well just do client/server.