I have gave it a thought and I can suggest the following.
In order to distinguish if the entry is generic or specific one can look at the name of the entry. By entry I mean Symbol, Component, Package and Device. We know that the MPNs are not standardized in the sense that they have different structures encompassing different infos about the device in their alpha numerics, like voltage rating, package type etc. On the other hand, what is fixed about the MPN is that it is always an alpha numeric with capital letters, no spaces and with or withouth dashes. The generic parts are usually words with the first letter of the word usually being capital letter and the others being lowercase letters, the name may or may not contain whitespaces and the first word in most of the cases is not a number. This is the structure in 95% of the cases. The rest of 5% are either really special cases, which I didn’t encounter yet, or sloppines of the user in naming things, which should be ignored. This structure can be also mentioned in the library conventions of LibrePCB but if you really design HW for a living this structure is already there. The packages can be also generic. The generic ones are usually mechanical stuff, like holes or so, and the special ones are defined by the IPC-7351 standard, again alphanumeric, caps, zero dashes or one dash, no whitespaces and one or more underscores. This mentioned structure can be exploited in the code.
I don’t know how you organized your code. Until now I didn’t looked into it. I assume that you defined a class for each entity and you also used inheritance. It’s my guess. Altough I see that Rust has different philosophy of dealing with classes and objects, other than C++. Anyhow, what I suggest is to define a filter function that checks the name entered by the user and assigns an attribute of that class that will say if the object is generic or not. This could be a boolean flag or a string. This attribute can be queried in the program and decisions can be made upon it like for example displaying the description or not. Later, the usage can be extended. The function is a method of the class, in the best case, of the upper class. The function can be also global and the return value is the response if generic or not but, I don’t suggest this because with global functions things will tend to be messy and may produce code overhead. Don’t know in this case. I need to be deep in the code to make the decision. For checking the name you can use regex or language API and you only need to check the above mentioned points. For example, a non generic device is a string with capital letters, numbers and no withespaces and 0 or more dashes, the latter being a weak argument. This can be refined during the test phase. The function should be kept simple and, even if not needed later, one can remove it easily from the code. This will be transparent for the user. The user should never know if the device is generic or special. It’s an intrinsic attribute of the entry. All of this should be manged by the program in the background.
A side note. You can include what you mentioned above like checking if the MPN list of the device has an entry. This will refine the filtering but be careful with this. If you look at my device list posted above, I have entries called “Resistor 0603 (0201)” and “Capacitor 0603 (0201)”. These may look generic but it contains some concrete MPNs for some resistor and capacitor values. In the end these two entries are generic. I did this because I don’t want to define for each resitor and capacitor value a new device. They have the same package and symbol. It is redundant and will only create clutter in my device list. I also need the MPNs for assembly. I know it is contrary to the convention but conventions are not always preactical. You also may notice that the names are the ones from the base lib. I had my hopes that by naming it like in the base lib it will inherit the attributes from there. What it did instead, it it created an entry whith the same name and I see them in the place device list in the schematic as duplicates. Yeah, nice try 
. I saw the post where it states that in order to edit the base libs you need to create a local copy of them. This smells like trouble for me. Inheritance is the most efficient way. There should be only one golden source and no duplicates. This is another topic for another post.
I hope this make sense or it should be inspirational at least. I am open for comments 
.
Best,
Horia
