This seems to be the approach that Elm is taking. (Although they're reluctant to add monads at all since they take ease of use seriously.)
Instead we get nice "English" names which only work for certain monad instances and fail to adequately describe others.
Elm uses "andThen" instead of "bind", which works pretty well for the monadic types in its core library. But you need to start stretching your imagination to see why "andThen" makes sense for other monadic types. Honestly, I'm fine with "andThen", especially in the context of Elm and the monads it implicitly uses. But in the wider world of programming where exotic but useful monad instances exist I'd rather stick to the most general name.
By the way, the more pressing reason for Elm not having monads is the fact that it doesn't have typeclasses (or a similar concept) and doesn't allow you to parametrize over higher-kinded types (like Maybe).
Perhaps "then" would work. JavaScript promises use it to good effect, and they're a monad.
(BTW, my own take on renaming a monad into something less scary is daisychain, or, slightly more to-the-point, chainable.)
(>>=) :: M a -> (a -> M b) -> M b