Ok, lots of people telling you it can't be done, and saying that it would break ECDSA, but not a lot of explanation about why or how to think about that.

Let's look at it this way....

I assume when you say "around the clock" what you really mean is that you've come back through the base point G, or rather that the point you've generated is equal to G plus something greater than the order of the curve.

Here lies the problem.  If you can look at a point (a public key) and know that you had to add G more than a set number of times to get there, then you could calculate the private key from the point:
Was it greater than half the order? No? Ok, how about greater than a fourth of the order? Yes? Ok, how about greater than three-eighths of the order? Yes? Ok, how about greater than seven-sixteenths of the order...  and so on until you narrowed in on the exact value of the private key.

There is no way to look at 2 points, and determine which one has the greater private key.

Points are added by calculating the line that passes between both of them, and then calculating where else that line intersects the curve. If you knew the private keys for those two points to start with, then you could figure out if the sum of the two private keys was greater than the order of the curve, but if you don't know the private keys, then you don't have any way of finding out what all the points are for all the private keys that you skipped over when you added the points together. As such, there's no way to know if any of those points were G.  Again, if you could know that some given private key existed "in between" the private keys of 2 given points, then you could use that information to quickly and easily narrow in on the private key of any given point.

Does this help you understand why your question isn't going to have an answer?  You are thinking about private keys, and how if the private key exceeds the order of the curve then it "wraps around" giving the same results as the new private key minus the order of the curve, but you aren't asking about private keys.  You're asking about public keys.  Since there is no way to calculate the private key from the public key, there's no way to know what the relationship is between the private keys for 2 given public keys.  Which is greater?  How far apart are they?  You either need to know the private keys to start with, or you need to calculate every point in between to see if any of them are G.

Now, if you want to do your demonstration by picking 2 private keys, and then calculate the public keys from them... That's a different story.  In that case, you already KNOW both the private keys.  If the sum of those two integers is larger than the order of the curve, then you've wrapped around, if it isn't, then you haven't.  That's a simple calculation, and doesn't need a script.

I assume when you say "around the clock" what you really mean is that you've come back through the base point G, or rather that the point you've generated is equal to G plus something greater than the order of the curve. (Yes this is what I mean)

Here lies the problem.  If you can look at a point (a public key) and know that you had to add G more than a set number of times to get there, then you could calculate the private key from the point:
Was it greater than half the order? No? Ok, how about greater than a fourth of the order? Yes? Ok, how about greater than three-eighths of the order? Yes? Ok, how about greater than seven-sixteenths of the order...  and so on until you narrowed in on the exact value of the private key.