SBE

When I parse a string from a fixed length SBE field, is the string terminated with a single 0, or how otherwise do I determine where to truncate? Conversely, when I populate such a field, should I ensure that the remainder of my array after the string is zeroed out or otherwise?

The string with either be null-terminated or will be of the size of the fixed length field. So if the string is smaller than the field length; it will end with a \0. If the string is the same length as the field length then there is no terminator. 
When writing you do not have to ensure the remainder of the array is all \0 values - although that would work. The string just needs to be terminated with a single \0; or if the string is exactly as large as the field length - you don't need to do anything.

The server expects string fields to be terminated with a \0.

Why is there no checksum in the SBE messages?

 It's worth remembering that the FIX protocol checksum is at the application level. The underlying TCP transport also incorporates it's own CRC and checksum checks.

The main reason this application checksum exists (in my opinion at least) is that the FIX protocol is a simple structured string and there is a real chance of it being mangled at the application level (not all FIX 'engines' are equal), which those transport-level checks would not protect against.

For SBE, code stubs are generated against the schema, using these to read/write a given message or field ensures it is well-formed. There are still ways to break the SBE messaging - e.g. receiving an enum value that is not supported in your stubs (i.e. schema compatibility issues). Any such error on reading/writing is a disconnection event.

In addition, SBE is a performance-oriented wire protocol. If checksums are included as for the FIX protocol, application-level checksum computation becomes a significant component of the overall cost.

Session Handling

If I wanted to keep a message store so I could resend messages, what technique would MF recommend?

A typical technique is to write every outgoing message to a memory mapped file at the same time as sending it down the TCP socket, for possible retrieval later. The file could be persisted to disk periodically if there was a need to keep it longer term.
If you don't need to replay messages to the venue, then just storing the sequence number is good enough.