Well, this is pretty much how exclude-moves work in WB protocol, and how the latest WinBoard beta version implements it. Except that I don't use any explicit buttons, but let the user indicate he wants to exclude the move, rather than play it, by double-clicking the piece, rather than single-clicking it. (And after that, either drag the piece, or click the to-square, as usual). And always toggle the inclusion state, so there is no need for having separate includde and exclude modes. See
http://hgm.nubati.net/news.html#tag-A1 .
The problem, however, is how to let UCI engines perform the required action. When the user excludes e2e4 from the opening position (say), the only way to do a search that excludes e2e4 in a UCI engine is to send it a 'searchmoves' command with the 19 remaining moves. To a WB engine, WB only sends 'exclude e2e4', and the engine will exclude it from its root move list, exactly like you suggest. But when the 'engine' in fact is an adapter, like Polyglot, it would now have to make this translation from e2e4 to all remaining moves, which cannot be done in a state-unaware adapter without rule knowledge without using the engine to supply a move list.
The design of UCI is really disastrous in this respect. For one, you cannot exclude any moves without aborting the search, and start a new one. For people doing hours-long analysis of orrespondence game this is really annoying. The 'exclude' command in WB protocol allows an engine to exclude moves from the current search without the need to restart the search, e.g. when the excluded move is a non-best move currently not being searched. So when, after 15 min of analysis, the user gets convinced that a position has only two reasonable moves, he can simply exclude all others without the need to redo the 15 min already invested, to speed up the search during the subsequent hour.
