Here is an attempt with some ideas pinched from http://en.wikipedia.org/wiki/Frame_Relay.
Start off each 64-bit chunk with a fixed header of 01110. Where you have more header info (e.g. sequence number or alternating bit flag, checksum...) you can probably arrange that the bit-pattern 01110 never appears. For arbitrary data, replace any occurrence of 0111 with 01111 - meaning that the effective data rate now depends on the underlying data. Have the provider of data to this layer make sure the data is pretty much random, e.g. by applying a http://en.wikipedia.org/wiki/Randomizer. I think your total data loss here is about 6 bits, which fits with the 6 bits necessary to describe a shift of 0..63.
In the receiver, look for 01110 to mark the true start of the chunk. If you do not see exactly one such pattern, you know that the chunk has been garbled. I think it takes at least a two-bit error to both destroy an existing 01110 and produce a fake one.
Garbles that cause chunk misalignment don't look like typical bit garbles, so CRC error rate calculations won't apply out of the box. I would include a non-CRC checksum in each chunk - perhaps a check calculated mod 31 or mod 961 so as to avoid the forbidden 5-bit pattern 01110, although depending on what abuts this you may need to be more restrictive. The chance of an error not being detected would then be about 1 in 31 or 1 in 961, with no particular guarantee about all single errors, unlike polynomial CRC.
I don't think you have enough space to do per-chunk error correction sensibly, but you could include N error correction chunks after every M ordinary chunks, using e.g. SECDED applied down the columns. You might have e.g. 57 data-bearing chunks and then 6 error correction chunks, treating each payload bit position as bearing 57 data bits and then 6 checksum bits. This should work well if errors tend to corrupt all or none of a single chunk e.g. by causing chunk realignment to fail.
after comment -
EDIT
OK, with one continuously transmitting message you have less bandwidth but relatively more cpu. Two things come to mind:
1) Given any sort of checksum or other constraint on the message you can achieve some limited error correction by e.g. considering all single bit errors, flipping a bit of the received message, and seeing if the checksum now works.
2) A message can be checked to see if complies with the bit-stuffing scheme suggested above by looking at only a 5-bit window passed over the message. I think this holds true even if you need to tweak it to work properly at the wraparound. This means that a message can be checked by a BDD of tractable size (Knuth 4A section 7.1.4). This means that you can count the number of 64-bit messages that comply with the bit-stuffing scheme and convert efficiently between message number and message (same section). So you can use this scheme without underlying randomisation or worst-case assumptions about the data to be sent, by just regarding it as an encoding of a number in the range 0..N (where N is to be computed via BDDs) and a 64-bit message. In fact, less elegantly, I think you could use dynamic programming with a 5-bit state instead of BDDs.
