if you're talking about OEP, this means you're learning how to get to OEP through the protector's code. In such case there are several other characteristics that can be used to find where protector's code finishes:
1) difference in EIP. i.e. protectors' code flows like a long set of instructions, and then finally it does jmp or call to some really far address. See UPX as example.
2) difference in ESP. The protectors' code allocates some stack for itself. Then after it made all its' tasks, it returns ESP to the initial value, necessary for real code to run.
3) some compilers just place oep at some constant place. For example, delphi (till d7 as i know) placed OEP as the last function in CODE section. I.e. you may just go to the end of CODE section and scroll up till you find it
But it requires visual instruction recognition skill
Because if you are looking into the dump, there will be just undefined instructions, because oep is still points to protector's code
And as I've said, you can find oep by signature, using the code from "hello world" samples. You just dump the application after the protector finished its' job. I.e. you don't even need to debug the application. Just run it, then dump it at any moment after it finished loading. Load the dump into IDA without any reconstruction, then search the code sequences that you see in "hello world" sample. And you'll be able to find the similar code and the approximate OEP.
Finally, when you've got the address, you may try to walk to that address via debugger. Sometimes you'll be able to set breakpoint to that address, and just see if it was hit. But usually you'll have to walk manually.
Or you can restore the dump, set the OEP address that you suspect and see if it work.
p.s. also you may try to get the protector which is used in the application, protect you "hello world" application with it, and see how your known code is changed by protector. Or walk in the debugger to already known OEP.