If for large models--and generally as a best practice--you choose to use an integer to represent the DateKey in a time dimension, you must then use an additional field as the DateValue which would have a data type of Date in Tabular. To then represent missing or unknown dates, you would need a dummy row, and you could choose either a strange DateValue like 1900 or, better, you can simply leave the DateValue blank for this record; this is especially important if your company is actually old enough to have fact data this old. Finally, you want to take full advantage of the Time Intelligence features in Tabular, so you use the "Mark as Date Table" option and you choose the DateValue column.
No errors are immediately thrown for your lone NULL DateValue, but your model will no longer process because the "Mark as Date Table" function has set the DateValue column as the row identifier which cannot have NULL values. This doesn't make a lot of sense and it side-steps a best practice for performance of using int or bigint types for surrogate keys. Moreover, if you actually try to use a date for your missing/unknown date row, your timeline control will not make sense, as it will incorporate this outlier-date into the timeline (also know that Excel--with the Timeline slicer--will not allow dates older than 1900 or greater than 9999--both of which seem to be unreasonable for missing/unknown dates).