It is by design that you get a handle back, even when the OPC ItemID is not correct. This is the expected behavior:

You get a handle as normally, and you are supposed to work with it as normally (unsubscribe when you no longer need it).
You will receive an ItemChanged callback with error indication. The Exception object of "event arguments" will be filled with corresponding information; the error from the OPC server should be either OPC_E_UNKNOWNITEMID (0xC0040007) or OPC_E_INVALIDITEMID (0xC0040008).
After some period, the component will re-try with the same ItemID again. This is to allow for OPC servers that change their configuration over time. If this succeeds, you will start receiving ItemChanged callbacks for that item with the data obtained from the server.

You see, usually there is no extra handling needed in your code for "unrecognized items": All you do is that you subscribe, and then process the notifications, and they always give you the current status, and they will always keep trying to bring the in the data.
The component goes through the list of items that have failed in such way with a period that we call "Topic retrial period" (defaults to 1 minute). At that moment, items that have failed and have not been re-tried longer than a delay called "Topic retrial delay" (defaults to 5 minutes), will be scheduled for re-trial. With the defaults, if any previously failed items becomes available in the OPC server, it should come back to live in the component in (5+1) = 6 minutes or sooner. The periods and delays are configurable in the code, or through the EasyOPC-DA Options Utility.