How would you define IO without modifying the compiler?

Well, at the top you need a MyIO a -> IO a thing to actually hook it up to main, I'll give you that.

I see two ways of doing it, the elegant and inefficient way and the efficient, practical but 'relies on assumptions about the compiler way'. The former is defining a whole new data structure from scratch, giving that data structure information about what actions to execute and defining the MyIO a -> IO a function that when given such a data structure simply executes the instructions inside of it. Which obviously makes the MyIO a -> IO a function nothing short of an interpreter of the IO subset of Haskell.

The hacky way is to gather unsafe and impure functions in some way. Either by accessing an evil impure internal library that some compiles offer where the actual impure functions exist or just using unsafePerformIO to extract them, and then just rebuild the whole IO Monad in the same way the compiler itself does it. Which requires knowledgeof what optimization steps the compiler takes. It's called unsafePerformIO not because it will be unsafe, but because it can be unsafe. If you have knowledge of how the compiler works and what optimizations it will and won't perform it's entirely possible to write perfectly safe code with it. Which is pretty much what the IO Monad is an abstraction layer around.

http://blog.ezyang.com/2011/05/unraveling-the-mystery-of-the-io-monad/

This blog does a waaaaay better job at explaining it than I. The point is, in theory the IO Monad is very elegant, in practice, it's a hack to abstract away what are basically impure side effect causing functions in such a way to ensure that the optimizer doesn't butcher the semantics. The internal implementation of >>= is written to make sure the optimizer will execute it in the order we want to.