The KERENAL does call ($314) first. The CPU will first jump to vector at $FFFE which normally points to KERNAL code that saves registers on stack, sets BANK 15, and then JMP ($314) unless it was BRK opcode.
Removing keyscan is very difficult, because the call to keyscan is burried deep in the IRQ routine after checking/changing various VIC registers.
You can disable processing of key scan values by re-direct vector $33a. Point it to an RTS and no keys will be processed by KERNAL. You should never do this in direct mode because it will 'kill' the keyboard. In a program, remember to restore the vector later.
Edit
I want to emphasize that this does not disable keyscan... keyboard will still be scanned and scan code saved in 212, but afterwords nothing happens (it will just RTS). Instead of simple RTS, you may want to test the scan code and decide if you should restore original decode vector.
;note IRQs must be disabled to change vector, for example inside an IRQ routine
ldx $33a
ldy $33b
stx save_decode
sty save_decode+1
ldx #<dummy
ldy #>dummy
stx $33a
sty $33b
...
;do not execute this directly, called by KERNAL
dummy:
;A = new scan code (same as 212)
cmp 213 ;compare with old
sta 213 ;save as old
bne exit ;different
cmp #88 ;no key
bne exit ;some key pressed
ldx save_decode
ldy save_decode+1
stx $33a
sty $33b
exit:
rts
So what that does is redirect the decode. The dummy decode just saves the current keyscan into old keyscan and tests if they are the same. If they are different then nothing happens. If they are the same and equal to 'no key' then it will restore the original keyboard decode.
This is just a simple example, you may need to do more complex testing.
Also, it sounds like your software is too slow! That is, KERNAL is detecting and processing key normally (in one IRQ) but in the next IRQ your software decides to do something special... but it is too late.
