This is an interesting problem to tackle because it deals with timescales that most of us are very unfamiliar with. My first recommendation to anyone dealing with such timescales is to read Stephen Baxter's book Manifold Time. It's one of the few books I've have seen which truly grasps just how strange life can get when making sense of how things are in the year 1,000,000,000,000,000,000,000,000,000,000,000,000,000 AD. Yes, that makes 300,000,000 BC/AD look pretty tame by comparison, and yes, Baxter goes much further into the future than that!
There's a few solutions to the issue you describe which have some history. The first key to all of these is that we are really trying to describe a "time point," and we typically want to do so using a number. The second key to this is that the purpose of such dates is communication. Our goal is to convey the concept of the time point to another individual.
Cycles are a very popular approach to dealing with large dates. Instead of counting numbers of days, we count in months, then years. Other cultures, such as the Mayans, had even more exotic cycles.
The fundamental reason cycles work is because the events we care about tend to occur on logarithmic timescales. Consider how many things we care about happening in a day. You might have 5-10 points in the day that matter enough to pay attention to. Now think about a month. Obviously you don't pay that much attention to the 150-300 points in the month corresponding to the 5-10 points every day. That'd drive you bonkers. Instead, you have 5-10 really important things to look forward to in the month, like pay day or someone's birthday. Look at a year. You might have 5-10 major events that you truly care about, like a family vacation or a major release of a product at work.
We currently are living 2000 years after the epoch of our current numbering system for years. This can be inconvenient, so we are known to shorten it to a 2 character year for convenience. As long as we're certain that '05 means 2005 and not 1905, this approach is very effective. Most time points we want to convey are within one lifetime, so we only need 2 digits.
If you think about it, this is really just a special case of the cycles solution above, which only works on cycles of 10 or 100 years (or whatever based numbers your civilization uses).
We're known to invent new epochs from time to time. When we do this, we define a new time point to base everything off of, and do math to convert one time into another. The most famous of these right now is the Unix Timestamp, which counts the number of seconds since Thursday, 1 January 1970 UTC (sans leap seconds). Why was 1970 chosen? Well, there's many reasons but one of the major ones is exactly the issue you describe in the question. If you're counting a number of seconds, that number can get big in a hurry. 32-bit computers could only count to just over 4 billion seconds, so they had to choose a time which meant most times that people in the computer age could care about fit into that window. 1970 fit the bill. Of course, they're running into trouble soon: on 19 January, 2038 03:14:08 GMT, the Unix timestamp will run out!
There is often a meaningful time where an epoch gets specified. Historically, many dates where given in terms of the ruler's reign. You might talk about an event that happened 5 years into the rule of King Henry. In more modern times, we defined a very important epoch for humanity in 1972, when we defined UTC in terms of atomic clocks. Nobody had every defined the second so precisely, so there was no way to determine exactly what the current time was when setting the first atomic clocks. The solution was that we defined a new epoch, such that all clocks would read 0 at that time.
Interestingly enough, we've also used the act of defining new epochs to go the other way. The single most common way dates are measured in the high-precision community is as a Julian date. For example, a major point in timekeeping forked off 2 additional time systems on Julian Date 2443144.5003725 in order to deal with time dilatation effects that had been unexpected until that point. Note that that date number is pretty big. Julian Dates are based off of the number of days since noon on January 1, 4713 BC, on the proleptic Julian calendar. That odd year number, 4713 BC, was chosen intentionally to be far in the past. It was designed to be so far in the past as to occur before any recorded history (as well as being the conjunction of several cycles deemed important at the time).
Measuring from the Present
This is a bit tricky, because it doesn't fit well with the math, but we measure time with respect to the present all the time. We talk about something that happend 3 hours ago, or 4 days ago. This approach has a disadvantage of being only valid at the moment in time where the date was uttered, but sometimes that's enough. We're used to working with a web of relative times.
If brute force doesn't work, you're not using enough. Humans may have trouble with large numbers, but computers don't. If your civilization becomes highly computerized large timestamps become easy to handle.
NTP timestamps are an excellent example. Right now they are 64 bit structures: a 32 bit integer number of seconds which will roll over in 2038 (with the Unix timestamp), and a 32 bit integer number for fractions of a second. However, there is talk of making them 128 bits long. This would be sufficient to measure times as "small as the time it takes for photon to pass an electron," and "large enough to be valid until the universe goes dim."
The key to this is that computers can handle these numbers so well. To a computer, the year 2015 is no more difficult to capture than Julian Date 2457023.5. Our number systems, with its place-based notation grows logarithmically, so each additional digit gives us another 10 fold increase in numbers.
This works great until the energy cost of storing a 128-bit timestamp in memory starts to become important. But for that story, read Steven Baxter's book!