I have done this exact thing with a similar device. I'm actually working on a blog post on reverse engineering it, but sadly it's low on my priority list and the list is long. :-(
These are all part of a very simple group of radio transmitters and receivers. They do not have any smarts in them so you can't just hook up a UART transmit pin or receive pin and expect things to work. It's up to you to send a well-formatted data stream that allows the receiver to maintain lock. Popular methods involve coding the bits in Manchester form or utilizing run-length constraining coding such as 8b10b.
It looks like your particular system is transmitting similar to what mine is; a constant bit time and either a long '1' or a short '1' pulse to signify the two logic levels. This is a very simple on-off keying implementation and it's pretty easy to both create and decode with any microcontroller. It's simpler than Manchester coding or expanding codes such as 8b10b, but you pay for it with reduced available bandwidth. This usually isn't a problem for these kinds of systems since you're not trying to maximize data transmission through the channel.
My particular receiver implementation uses an AT90CAN128's Timer1 peripheral configured in capture mode. I set up a 64us free-running timer and then whenever the receive line changes state the timer peripheral captures the timer value and signals an interrupt. From there I just look to see how long the 'high' time is by calculating the delta in timer values and if it's above a threshold its a 1, otherwise it's a zero (and if it's too short I consider it noise and ignore it). I gather up these bits by shifting them into a variable and when I've gathered enough of them I send the 32-bit value into a little software FIFO and signal my main routine that there's data to process.
For transmitting you can do something similar. Set up a timer with a tick rate that is "nice" for your particular application. (from the picture it looks like about 500us good, since the bit time looks to be about 2ms and the "short pulse" width is about 500us). You want a constant bit time, so you need to transmit one of two states: high for 1.5ms/low for 0.5ms or high for 0.5ms/low for 1.5ms. You can do this with timer overflows or go a little fancier and set the timer to automatically set/clear the pin based on value, if the peripheral allows it. You can probably get away with it by abusing the PWM feature as well. For simplicity, I would make sure you can accurately sleep for about 500us and just bit-bang it. Get it working, then get fancy.
Anyway now to reverse engineer it. Remember that I said these radios are dirt-cheap and dead-simple. You can see from the graph that there is a constant sequence of 16 bits: 0101010101010101; this is to allow the receiver to lock on to the signal. After that it looks like the actual button press is probably sending the 8-bit value 00001101. There's one 0 bit left, which is possibly parity or just used as a stop bit. You will be able to see what's going on if you press other buttons. In my particular reverse engineering adventure for these transmitters I was reverse engineering the protocol used to transmit temperature and humidity. I guessed correctly at the 1 and 0 state (it could have been reversed) and I guessed incorrectly at the bit order (it was LSB, I guessed MSB). There was also a "battery low" bit and a parity bit that I eventually figured out.
Recreating the transmission is just a matter of sending the values you've reverse engineered to the "raw" radio module using one of the methods I described above. You feed those values to the transmitter module and voilà!
