In short? yes! You might want to add series resistors to both the lines (Tx->Rx, and Rx-> Tx) just incase something goes wrong. Something like 1-10k sohuld be fine.
You can of course use the data recieve interupt to 'read' the data. In fact, its probably the best way of doing it rather than polling the 'data recieved' flag.
The maximum baud depends on the oscillators in the PIC's. If they are only a few centimeters apart, I woudn't have thought you'd get much in the way of noise/signal degredation. Look at the datasheets and find the 'maximum' baud rate for the crystal osc's you're using. It'll probably be up in the MB/s range. If you wish to go even faster, PIC's USARTs have a sync mode, whereby a master produces a clock to go with the data, much more stable at high datarates, and can approach 2.5MB/s. Although as I said, one has to be a master and one has to be a slave (only the master provides the clock).
For async mode (normal USART operation) I would pick a baud that is perfectly accurate with your clocks. No point in configuring it for 19200 if you're oscillator would give the baud rate generator a % error. Check out the datasheet for the PICs and the BRG.
Alternatively you can use the SPI (MSSP) module to transfer bytes between the micro's at very high speed. If the PIC's are on the same board, and a few CM apart, then a good 5Mhz wouldn't be too tricky. Again with SPI, one has to be the master and one the slave, so only one provides the clock. On a side note SPI is a data exchange protocol...that is...when the master sends a byte to the slave, at the same time data is 'taken' from the slave.
Blueteeth