Yes, I have connected a serial module to the Onion (an EnOcean Pi module), see below. Once you get it working hardware-wise I'd be interested to hear more about LoRa+Onion; that's something I'd like to experiment with myself some time
Now for the serial port:
First of all, these TX+/- and RX+/- lines are the Ethernet connections, not the serial port.
The actual serial port is on the Omega's J1 (right side) connector, pins 5 and 6, see wiki. These pins are not available on the expansion dock's connector, but are internally connected to a Silicon Labs CP2102 serial to USB chip, to make the serial console available via the micro USB connector to a connected computer. You can see that in the schematics of the expansion dock. The schematic also shows that fortunately, there are resistors in these connections. This means that altough the Rx signal is driven from a CP2102 output, it can be overridden by a direct connection to the Rx pin on the omega itself, without the risk ruining the CP2102 or the connected module (current is limited by R91 to 3mA max).
So that's how I connected my module - simply soldered two wires to pins 5 + 6 of the omega J1 connector, and connected these to my module's RX and TX. Of course, the module must be 3.3V powered for that - if it is 5V powered, the level on TX could damage the Omega! In my case, the module has very low power requirements so I just powered it off the 3.3V available on the Expansion Dock.
Then there's a software side to take care of: the omega uses the serial port for the system console, which means your module will see all kernel messages, and your module's output might be seen as login attempts.
To get the serial port for myself, I had to do two things:
a) Prevent the kernel from writing any messages to the console:
echo "0" >/proc/sys/kernel/printk
b) prevent openwrt from awaiting a login on the console:
Comment out the last line in /etc/inittab as follows:
Note these steps do not completely detach the serial port from the kernel (to do that, one probably would need to change the kernel command line in uboot). This means, at startup your module will still see kernel messages. And, if your module emits something at early boot, it might even get interpreted as input to uboot or failsafe mode and prevent proper bootup.
I could solve this problem because my module has a "reset" pin. So I connected this to a GPIO such that the module is kept reset at startup, until after the kernel is silenced (printk in a custom init.d script). Only then I toggle the GPIO to activate the module, and can talk to it via /dev/ttyATH0 undisturbed.
Hope this helps!