At around 27 €, this LEA-6T module is perhaps one of the cheapest solutione with two timing outputs - see
http://www.eevblog.com/forum/projects/ebay-u-blox-lea-6t-gps-module-teardown-and-initial-test/

Although the LEA series has been superseded by NEO-7 and -8 with GLONASS and Galileo capabilities, but these tend to be much more expensive.

My unit arrived within about a week, and started up fine through the included USB adapter board. Unfortunately my device did not remember settings after powerdown, which turned out to be due to a missing flash eeprom chip, and also (believe it or not) a faulty solder joint on backup-battery charging resistor. In fact all the solder joints looked as if they had been hand soldered in a Chinese garage factory but that's fine with me.
 
Then I connected the timepulse outputs through 470 ohm protection resistors and separate coax cables. With 3.3 Vpp behind the resistor we get ~ 1 mW available power. However connecting the little ublox module barefoot to the antenna produced good carrier traces and successful EbNaut decodes at the DL0AO MF-Grabber, 48 km from here. For PA switching, I later employed a simple VOX circuit fed by TP2 output signal.

The frequency can be set at any integer Hz from 1 to 24 MHz. The stepsize is fine for LF and MF but perhaps inconvenient at VLF where we would rather avoitd integer Hz frequencies. But it may be possible to create small and precise sub-Hz offsets by regularly advancing phase, using the user-delay field. Note that at higher HF frequencies, a noticable degradation of GPS sensitivity occured presumably due to interference to the on-board ceramic antenna.

EbNaut generation:

The idea for ebnaut is to generate PSK by using ublox commands to change polarity of timepulse, minimizing hardware and doing away with audio mixers or external phase switches. I started by monitoring the 40-byte TP5 commands in in the binary message display. Then based on the specificaton on the u-blox website,
https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf
(chapters 23 and 31.24.3), I wrote a small Basic executable setubx.exe which reads a template and patches the frequency, flag and checksum fields. The output can be redirected to the virtual com-port of the USB device (e.g. >com6).

Note that any changes are not executed immediately but only at the start the next second. If a command has been issued as early as 1 to 0.1 s before, the output inversion happens about 50 ms after the tick (implying a negligible 0.05 s extra symbol delay). The advantage is that no subsecond timing is required for the issuing of commands, enabling the use of simple DOS timeout or sleep functions. On the other hand, the maximum signalling speed is thus limited to 1 second per symbol.

As mentioned before, I have created a directory for Windows scripts and a few screenshots, and also this email:
http://df6nm.bplaced.net/LF/u-blox_ebnaut/

To prepare an EbNaut transmission, you'd go through the following steps:
- download and unpack ebnaut_ublox.zip
- use Paul's ebnaut-tx.exe and "write lines" to produce a pskln_xxx.txt output file,
- edit the file with notepad to replace "1" by "call 1" (same for 0) and save as a .bat file,
- right-click and edit frequency and delay functions in 1.bat and 0.bat  
- edit the send_ebnaut...bat according to your desired transmit schedule.

BTW I did struggle with strange peculiarities in batch scripting... We need to wait until the second before the next of 3-second-multiple, but why this cryptic notation:
@set /a waittime=2-(3%time:~6,2%%%3)
- set /a is for arithmetic calculations for a variable,
- %time:~6,2% provides two digits for the seconds in a minute,
- %% is an expansion of the % modulo operator which is required in a batch script,  
- 3%time:~6,2% expands xx to 3xx, only to avoid 08 being interpreted as an invalid octal number.

Spectral purity:

Originally I had hoped for relatively low jitter, as little as 21 ns from the 48 MHz clock. But it turned out that on most output frequencies the jitter is really much larger, leading to relatively strong 1 kHz spaced spurious sidelines. It looks as if frequencies were internally generated on a relatively coarse raster, and then the phase is being pulled in periodically each millisecond. But some preferred frequencies are much cleaner than others, specifically
 - integer divisors of 48 MHz (well-known and easy to understand),
 - but also all multiples of 366.2155 Hz. This raster happens to be 48000.34 kHz/2^17, so I speculate that this may be a "DDS"-like architecture, clocked by my particular 48 MHz crystal, and outputting the msb of an overflowing 17-bit-counter.

When the output frequency is set slightly above one of these sweet spots, the level of 1 kHz sidelines gradually increases. But going only 1 Hz below the spot produces a sharp detoriation to the worst levels. For example:
 137330 Hz -15 dB, 137331 Hz -54 dB,
 137536 Hz = 48 MHz/349: -54 dB,
 475710 Hz -5 dB(!), 475712 Hz -47 dB.

When sweeping through frequencies, a "sawtooth-like" dependence of spurious levels can be observed (screenshot lea-6t_sweep_474-480.5kHz.png).

Hope this may be useful…