No, absolutely not. If that were what invariably happens, we could use that to our advantage and specify it in the standard; known behaviour, even if it is a crash, is virtually always better than unknown behaviour.
But instead, the system response depends on details of the implementation, of the previous actions of the program, on the state of the runtime etc. in an unpredictable way. On modern operating systems referencing an address that doesn't belong to you may usually trigger a segmentation violation, but definitely not always. A segmentation violation might occur, but not until much later. Even worse, your program might appear to work but silently do the wrong thing. That's why the language standard has to take the worst possible option and declare that the behaviour is undefined.
(Note that goodness depends on your viewpoint. For the compiler implementor, undefined behaviour is good because it means that whatever you do is, by definition, right. For the application programmer it is bad, because it leads to application errors, and even to the particularly insidious kind of errors where things sometimes work and then fail spectacularly at the least opportune moment.)