Is it possible to have xid before and after wrap around with the same timestamp?
Assuming updatedAt stores the transaction timestamp as reported by now() or CURRENT_TIMESTAMP. See:

Difference between now() and current_timestamp

Then yes, xmin behaves like a simple sequence, basically.
But you may want to look at cmin additionally. The manual:

The command identifier (starting at zero) within the inserting transaction.

Related:

How did this statement update 3 rows in Postgres?

And, subtransactions (incurring a SAVEPOINT) may very well interfere with your plans, as those advance the transaction ID (and hence the xmin of rows written after that) within the same transaction, while the transaction timestamp stays the same.
So, that's a YES to the question in the title. It is possible to have xid before and after wrap around with the same timestamp.
There are various ways subtransactions may get involved:

Calling the SQL commands manually, obviously
A PL/pgSQL block with an EXCEPTION clause
The ON_ERROR_ROLLBACK setting in Postgres
Some replication solutions involve savepoints (I think)

Related:

How to view tuples changed in a PostgreSQL transaction?

Related discussion on ppgsql-general