Well, if that would be true then the difficulty adjustment would also not work. In order to be able to adjust the difficulty you need to know how long it took to generate the last 2016 blocks. So there *is* some knowledge of time. It is not exact, but it is there and it is sufficiently precise to make adjustments of difficulty that keep the block generation from getting runaway.

My idea is to use these ideas from that code that do the difficulty adjustments to implement the scenario described. Regarding the time source I was thinking about some sort of NTP-like time propagation protocol which the clients would use to track something called "current network time". A NTP service could be used by random nodes to obtain the current time but the real NTP queries should be very infrequent and made only by a few nodes, essentially the network should collectively keep track of time. The nodes shall poke throughout the network, asking random node about the time (and JUST only about the time) and then update their clock accordingly.