In a SSL handshake, the client and the server exchange handshake messages which are encoded in records. If your protocol variant consists in additional handshake messages then you have a problem: at the end of the handshake, two
Finished messages are exchanged, and their contents are computed as a hash function over all previous handshake messages, therefore including your extra messages. Corollary: if you have extra handshake messages to insert, you MUST modify the SSL client tool, because that tool computes the hash and will compute a wrong value if it is not aware of your extra messages.
If your protocol variant consists in extra records of a type distinct from "record for handshake messages" (type 22 in the standard), and such that the extra records do not impact the computations of the handshake, then your filter strategy might work. You would have to:
Intercept connections; there are several ways for that, but the simplest is to change the configuration and/or DNS so that the source machine connects not to the target server, but to a server of your own, which itself connects to the rightful server, and relays data in both direction.
Parse the data so that you detect the handshake records, to know where and when your extra messages must be added in the flow (and, similarly, extra messages from the server must be analysed and removed, so that the SSL client tool does not choke on them).
So you are in for some programming. The record protocol of SSL is not complex, as long as you fiddle with the unencrypted records (those before the completion of the handshake); see the section 6 of the standard. Also, see this answer for a detailed introduction on the protocol (which I believe to be easier to read than the standard). For the relaying, the simplest implementation strategy would probably to launch two threads, each thread running in an endless loop of read-from-one-machine-write-to-the-other.