Stepping back: you don't even need to trust initial hops based on their identity - they can offer proof of how many hops their routing chains accumulate by showing users those transactions, linked to historical blocks, which are expensive to fabricate.
You can use a succinct commitment scheme to prevent would-be Sybils from only sharing their 'well-routed' transactions: A node commits to a Merkle Tree header hash, and the user is allowed to randomly sample from branches in the tree.
A user expects to be provided with their random sample and see that:
1) The transactions are from a sufficiently 'worked' on chain which is prohibitively expensive to fabricate.
2) The transactions involve the router committing to the Merkle Tree.
3) The transactions involve less hops than other routers the user is sampling transactions from.
The Sybil you are describing now must divide the size of their Merkle Tree sampling for every new identity they wish to inhabit - and if they are in fact consistently Sybilling users, will be forced (statistically) to reveal their excess hops.
What you describe is still very inconvenient for users - to have to sort through all these nodes and compare their samplings, but it is at least a demonstration that this Sybilling behavior is not sustainable. I tried to assume the worst case scenario (related to your concern) when devising the above scheme.