My opinion is that rather than having a missing entity represented as an alternate type, we would be better to describe the provenance of the data we have in all entities in some way — such as tagging with attributes or relations, something simple such as: known/given, vs. derived/computed/inferred vs. assumed, or something more complex capturing who/what/when.
In a relational model, different types of entities will mean separate tables, which imposes burdens on queries. In OOP, different types will impose similar burdens unless inheritance is used to unify the concepts — and to that I would say composition over inheritance: in this case composition of provenance information over inheritance of (provenance) types.
is there a common term that is already established to represent this kind of known missing data?
Not that I'm aware of the way you are describing it, but there are notions of provenance of information, and these notions can range from simple to complex.
Otherwise, in relational model,
NULL is used to represent two sadly conflated notions: (1) missing and not applicable, and (2) missing yet applicable (or simply missing data). Your description goes to the latter use of
NULL in SQL.
(The former, missing and not applicable, means there are really different types in the same table, such as when a CEO does not report to any one individual (and never will: the data is not missing or unknown, the column "not applicable" to this row) so has their
reports to column as null, unlike all the rest of the employees who do and must report to someone.)
FYI, there are other concepts such as futures or promises, that are effectively proxies for not yet available information, though these are deeply related to programming models (threads, async activity, other behaviors), and less to information storage of domain objects.