Electrically, the simplest and perhaps most robust route is to use center-tapped transformers to inject a differential digital signal onto a pair. Each pair then carries a fixed DC voltage plus a differential signal over it. That's how Gigabit Ethernet PoE works, although you won't be able to reuse those transformers since you presumably need way more than 2A per pair.
The digital differential signal needs to have a constant DC mean at 50% of its p-p voltage, in other words it needs to be "DC balanced". In practice that means that there's, on average, the same number of ones and zeroes sent over the cable. This can be achieved in many ways, but a common way is to use a DC-balanced code.
The DC balanced codes can have fixed disparity, where for every code digit sent, there's only one way to encode it, and that encoding has the same number of ones and zeroes.
The DC balanced codes can also have a variable disparity, where certain digits can be encoded in more than one way, in order to keep the disparity at zero over a time window of several code words. The encoder keeps track of accumulated disparity and choses the code word to use from among the alternatives to steer the disparity towards zero. A common approach is to have two encodings for each data symbol, one with disparity of +1, another of disparity of -1.
To make life easy, a fixed-disparity code can be used. Say you have a 6-bit code word, with 64 possible code words. Out of those 64 code words, 20 have zero disparity, and it's convenient to use 16 of them to represent 4 bits of data. The other 4 code words then become control code words, and can be used for synchronization, as the link idle state, etc.
So, for simplicity, you can use a 4b/6b code, where each byte you send takes two 6-bit code words, one for the lower nibble, one for the upper nibble.
Zero-disparity codes are also self-clocking, since there are always transitions on the bus, so on the receiving end you can run a PLL to recover the data clock.
There may be existing chips that implement the nitty-gritty of this, but a small FPGA will do it all as well, and the "PLL" can be a DPLL that samples the output of the differential receiver at a rate much higher than the transmit clock rate. So this can be very robust, and defined entirely in VHDL or Verilog without need for any special/fancy function blocks.
simulate this circuit – Schematic created using CircuitLab
The pairs for power can be paralleled of course, and they'll increase the data bandwidth as well. With six pairs available, you'll be transmitting triples of 4b/6b codes in parallel.
If you don't have bandwidth to design it yourself, and can't find an off-the-shelf solution, it should be something that could be easy to subcontract out.
Personally, I'd use the buried cables for power only, and use point-to-point off-the-shelf RF links that route Ethernet over the air. These are used by Fixed Wireless Internet Providers (WISPs), and can be easily procured. The link will be very fast, and you won't need to worry about PPP and serial - it'll all be interfaced via standard Ethernet ports.
The transceivers would be standard RS-422 parts with good ESD protection. There also needs to be line termination, matched to the measured characteristic impedance of the pair. You can use a TDR to measure the effective impedance of each pair.
It will probably be able to run a wee bit faster than 38400 baud.
