This is due to the program doing a SetCursor with NULL making the cursor invisible using GDI, then doing a SetCursor with DirectX to set the cursor visible again. Whilst I do not the exact mechanism as to why it causes FPS issues, I'd guess that it's due to some kind of GDI/DirectX synchronization having to occur.
A workaround is to patch byte at 00216FA5 from 00 to 01 In mb_warband.exe (for steam version at least). This causes the SetCursor to fail thereby preventing the aforementioned hitching. In my system my FPS became steady and never once dipped again.
Side effects may include a cursor being visible when it shouldn't be (though I doubt it).
This may be an NVIDIA bug, it might be a Windows GDI bug, but really, ultimately, this is just a poor programming bug. There is no reason I can think of why the cursor must be hidden by GDI just to be shown again by DirectX. Perhaps editor mode? Maybe?
EDIT: -- I'd like to point out that after further research the above is actually valid and usual way of handling this according to the Microsoft documentation. Why this causes flickering is unknown, and why ignoring the setCursor fixes it is also unknown.
Anyway, I develop programs for my real life, and I've written an automatic patcher to make the single byte change above (for steam version only), I'll link it below (if it works, not sure if the forum will mangle it).
It's an exe file because that is easiest to distribute. Reminder that you should never download .exe files the internet, but here you go: