Absolutely yeah. What I would do, would be to have a map of Item ID values to “Constructor” classes. Register each constructor class with the associated Item ID. The constructor would take the Item as input as well as the Actor calling the constructor. The constructor would then be free to do whatever it needed to add functionality (in my system it simply added the required components since I was using a far more component oriented architecture). When I say constructor I don’t mean C++ class constructor btw. Maybe find a better name 
but the point is that having a class that handles construction/removal of the parts needed for the item was the way to go. Those classes would register themselves with a central registry such that when you did anything with an item the associated mapped class would deal with the events. I’m a bit hazy on the details here as it was a while back, but I had events for adding/removing from an inventory for instance. I also allowed inventories to hook their own events too, so they could do stuff like recalculate total weight/value.
For the model dropping in world stuff, I simply had that as part of my Inventory component class for convenience. Oh yeah! the other thing is I’d recommend having Inventory components. Allowing multiple InventoryComponents per actor. I had I think maybe three by default? One was the Equipped items, one was the Quickbar items, one was the storage inventory. I had a UI system that could take any inventory from an inventory component and display it in a grid.