Really, your problem boils down to showing exact vs "fuzzy" dates. There's no one single strategy, but I've had a somewhat similar requirement before and handled it by having a start date, a fuzzy start, an end date, and a fuzzy end, all nullable.
If you know any exact portion of the date at all, you use the actual datetime field. For example, if all you know is 1880, you store it as 1880-01-01. If you know the year and month, you just make the day 01, and of course, if you know the full date, then you store that. Now, granted, this can potentially be problematic. How do you know it wasn't literally built January 1st, 1880, versus just generically 1880? Well, that's up to you to decide how to handle those situations. You can just assume that any 01 is the same as a null value for that date portion. For whatever reason, buildings don't tend to open on January 1st, or really the 1st of any month, but there could always be an exception out there.
If you do need greater precision, you might need to break the date apart and store it literally as year, month, and day - all nullable int columns. Then, you can simply piece it together however you like when it comes time to display it.
The "fuzzy" date columns would be strings and are where you'd store more nebulus "dates" like "Victorian Era", i.e. you may not have a true date or even year, but you know it was during some period of time. You could do the same with things like "19th century", but I'd personally prefer to store that as 1800-01-01 and then intuit that it should be displayed as "19th century" when there's a date of that form.
Another option is to use both the date and the fuzzy text. For example, you could store it as 1800-01-01 and "19th century", and then you can make the determination that it's not literally January 1st, 1800, based on the presence of the fuzzy text not being null. That can help solve the ambiguity problem described previously, as you could do this for all such cases. For example, if all you know is "July 1880", then you can store that in the fuzzy text, and set the date as 1880-07-01. Then, based on the presence of the fuzzy text, you can choose to decipher the 01 portion as essentially null, versus literally the first of the month. If there's no fuzzy text set, then you assume it's an exact date.
As far as representing it on your model, I wouldn't use actual DateTime properties or DisplayFormat. You'd be better served by having utility methods that can work over the logic and return a pre-formatted "date". Then you'd simply do something like @building.GetBuiltDisplay(), and return all the information you know (including start and end if you have it) already formatted.
In one of more interesting projects that I recently looked, they did that in quite interesting way : int century, int? year, datetime2? exact_date. If century and/or year is known, exact date is not important (it can be broadly filtered by known data). Of course it will take some more space, but a lot easier than dealing with arbitrary dates like 1899-12-31 or so. Edit : project was personal collection system for historical item tracking.
@ChrisPratt: "year, month, and day - all nullable int columns." why not ushort, byte, byte ?