I need to step in here and clarify a couple of things so you don't have a huge set of problems to over come. First, if you're going to use the XBee library, be sure to get the very latest one. The previous versions would NOT talk to the additional serial ports on the 2560. Paul Stoffregen has modified the library to work really well using the Serial1, Serial2, etc look here:
Seems the work he did to make softwareserial better translated into something great. Take a look at his blog post here for more information.
I recommend using this library because it leaves the Serial port open for debugging and monitoring status, and you don't have to worry about the various things that can happen using digital pins. I have an example of using it on my site that is specifically targeted to the mega2560 and using its additional serial ports:
http://www.desert-home.com/2012/10/using-xbee-library.html and http://www.desert-home.com/2012/11/using-xbee-library-part-2.html
Feel free to steal them.
Next, broadcast is a bad idea if you have too many nodes. I did this and ran into trouble when I reached about 7 or so nodes transmitting data. What happens is that the remote nodes get retransmitted by the intermediate nodes and this increases traffic and chance of collision. With increased transmissions and collisions, comes retransmissions which increase traffic and collisions. The whole network will bog down and bad data becomes the norm. This happens because the XBees work very hard to make darn sure all broadcasts get to all the nodes on your network, something that is usually not needed. When I switched to having the nodes transmit directly to my concentrator using the address, the problem went away completely. My concentrator, the device that gathers the data, is NOT my coordinator. My coordinator is a device that does almost nothing except coordinate and broadcast (yes broadcast) the time for the other nodes to use. This way, the coordinator has plenty of time to ... well ... coordinate.
Last (at least for now) API mode is the way to go. If you use transparent mode, you can fall into the trap of sending partial data. Especially if you use strings to carry the data. I use strings that have the data in ascii for the most part since I want to set up a sniffer and watch what is going on from time to time to be sure the entire network is doing what I want. Things like, "device1,on" and "temp1,76" fly around my network. This makes it, relatively, easy to see what is happening. So, the strings can get cut in half by the transmission priority and various timing factors in the XBee software. I saw "tem", "p1,76" in two separate packets with other devices data interspersed between many times when I was using transparent mode. Switching to API mode fixed that entirely. I still get occasional collisions and bad checksums from time to time, but it's the exception, not the rule.
These things allow me to have a network that is essentially a "bunch of kindergarteners, all screaming at once" because the XBees themselves try very hard to ... coordinate ... (love that term) their activities. They automatically sense traffic and have built in retries that self-correct for many problems. See, I want devices to report changes when they happen, not when something gets around to asking for it.
But that's just me.