TI CC2538 radio turns off after connecting UART

Take a look at the Atmel SAM3S. It is not a 16 bit device but I'm not sure why that is a key requirement. I'm also not sure what "low" power means to you. This will be in direct conflict with the requirement for the fast baud rate. To hit the 3.25 MBps you have to run this part at 52 MHz (It runs at 64 MHz max). Another nice feature it has is DMA to help move the high speed serial data. It also meets your memory requirements.

I would guess that the problem is not actually occurring when the PIC wakes up, but rather when it sleeps. If the PIC goes to sleep between the time the code enqueues a character for transmission and the time the UART finishes sending it, some bits of that character will get sent before the PIC sleeps and some will get sent after it wakes up. The first falling edge that occurs after the PIC wakes up will likely be interpreted by the receiver as a start bit rather than a data bit. If a start bit occurs within 8 bit times of that, the receiver will not detect that as a start bit, but will instead detect the next falling edge (which may well be some other data bit). This condition is referred to as a "framing error"; note that nearly all framing errors will cause incorrect data to be received, but only some will cause the "FE" bit to be set.

It's worthwhile to note that when sending a byte value of 00, 80, C0, E0, F0, F8, FC, FE, or FF, it's possible for a misdetected start bit to cause an incorrect value to be received for that byte, but the byte following one of the above values should be received correctly in any case (since will be no falling edge between the start bit of any of the indicated values and the start bit of the next byte). By contrast, if a framing error occurs on byte value in the range 40-7F, it's likely that the next byte will be corrupted as well, since there's a falling edge between bits 6 and 7.