I can't say I have played around with controller hacks for the NES but the general theory is the same regardless of system and I will detail that.
Frame advancement is possible. Not the suggested method really though. The only people really doing anything like that would be tool assisted speedrun people that need frame accurate inputs for their runs, or maybe some people doing lua scripts (FCEUX does have class leading abilities here so I can see it).
Most people would probably come the other way though and set a breakpoint/watchpoint on the hardware register that reads the controller state, or in many cases where that gets debounced* to in normal memory.
For actions in a game it will tend not to be a check every frame** type of routine (hopefully anyway -- such a thing burns CPU power and batteries when on handhelds so it is bad programming) and instead some kind of interrupt.
As such a thing will inherently be in response to the button that should hopefully get rid of any incidental code running at the same time. It could be that two routines run independently and care about the same button press but this is rare. Instead most things will be serial in nature, and even without it then it should be fairly obvious pretty quickly if what is happening is what you are concerned with.
On the flip side I think FCEUX does have that new routine scan option if memory serves. Most people use it to find other things but it would work for this. I forget the name but the general idea is you tell the thing to activate, then do everything but press the button you want for a short bit of the game (whether you can mess around in a starting area or something is game by game really). Tell the emulator that whatever happens next that did not happen before to take note and tell me. Press the button of choice. As all the music, graphics drawing, timer, life... should have happened before then hopefully the only new routine called will be the one that cares about the button. Not all emulators/debuggers will have this functionality, indeed I dare say most won't, so don't rely on it being there for any given system. Also as games are pretty random things when all is said and done (code wise them being about as far as you can get from the classic "convert this database from this form to this form" program) you do risk a false positive for something where the method above will not fail you if you implement it correctly.
*debouncing if you are not familiar with the concept then. Switches are typically binary things (on or off/closed or open) but as they are based on physical things then it is entirely possible some small amount of stretch, corrosion, wear... makes it appear closed one millisecond and open the (and then closed again...) next despite your thumb having not released it or being in the process of it. Rather than suffer strange behaviours there, or have to have things reach out to the hardware every time something wants to know, or have to program around all this then many games/systems will copy the contents of the control state once per frame (maybe longer but hopefully not) and have everything operate off that for the next however long. This also provides you a nice location to do a probably game, or minigame, wide button swap hack as you can easily flip bits around here but I will leave that one for now.
**more modern PC games will decouple input from frame rate, or increase the input polling rate to multiple times per frame but for consoles and games we are likely to deal with around here then assume a debounced hardware section. Also it is still a hardware section that is read/copied so it still applies after a fashion.