I have a feeling that this project is on the limit of the 18F series chips with PBP.
Eventually you may need to do a lot in assembly or finally select a 24F chip and C compiler...
If they could do this in the early 90's then we sure as hell should be able to do it now, with PICs running PBP code at 64MHz, DT-Ints or no DT-Ints.....

I really have not seen the spec's of the DMX512. Is it necessary to send data continually?
The specification really only says 1 frame per second minimum but that obviously won't work in practice.

Note that if you're using a pic uart to send data you'll have to generate the second stop bit using a delay of 4us between bytes, but that's not normally a problem.
Not sure about that, may depend on the PIC used but at least the 25K22 family supports 9bit transmission, the 9th bit normally being used for parity. Simply enable 9bit transmission and keep the 9th bit at a logic '1' and you'll have your second stop bit.

For the transmitter I found it easier to generate the DMX BREAK signal using an extra IO pin.
Good idea, however I'd just disable the UART for the duration of the BREAK period, this drives the output pin to whatever state the LAT register dictates. Equally simple but saves an output pin.

use two 512 byte packets... one for the main loop to fill (#1) and one for the ISR to transmit (#2).
Using a double buffer may have its merits but since each channel is a single byte I don't really see the need for it. Is there REALLY a need to keep all channels in sync within 25ms or even less?
Perhaps some special type of fixtures/lamps/whatever uses TWO channels combined to get a 16bit value in which case you COULD potentially change one byte of that value while the other one is being sent but then again, if the update rate is >40Hz, will anyone even notice?

Nah, based on the tests I made, running a PIC at 64MHz should allow you to keep up with the theoretical maximum framerate - even WITH DT-Ints.

/Henrik.