Wordpress - Avoid converting ">" to >

Filtering the_content

function wpse72941_content_filter( $content ) {
    $new_content = '';
    foreach( preg_split( '/((\r?\n)|(\r\n?))/', $content ) as $line ) {
        $new_content .= preg_replace( '/^>/', '>', $line ) . '\r\n';
    }
    return $new_content;
}
add_filter( 'the_content', 'wpse72941_content_filter', 1 );

I don't know your markdown plugin - for the above approach, I have assumed that the markdown is interpreted after the post is retrieved from the database and not before it is saved to the same. I.e. that the markdown plugin also filters the_content.

The regex ^> matches > iff those are the first four characters of a string. In the above, the content is iterated over line by line, hence all > entities at the beginning of a line are converted back to > characters.

When the filter is added, we set the priority high (1), such that our entity conversion will run before the markdown interpretation.

The above will work when added to your theme's functions.php, but probably would be a better fit in a plugin. Actually the markdown plugin should take care of it itself.

Preventing TinyMCE from converting entities

If you need to stop the entity conversion right where it happens, before it is written to the databse, you will have to alter TinyMCE's (the editor's) configuration, the entities and/or entity_encoding options look promising.
There is the tiny_mce_before_init filter that can pass custom config values to the WP editor.

I would have provided a working example as well, were it not for this:

Encoding Type: raw | All characters will be stored in non-entity form except these XML default entities: & < > "
from the TinyMCE documentation on entity_encoding

So for the specific entity in question, this appears to be more involved.
This might also be the reason for why disabling the visual editor might not suffice.
Possibly a combo of 'named' as a value for entity_encoding and a list without gt for entities might do it.
Otherwise the onPostProcess event would be a last way to go.

Life would be simpler though, if the above assumption was true and filtering the post on database retrieval would suffice.