It's not formally defined, but it's trivial since === is literally just pointer equality.
However, I would be strongly opposed to repurposing === for what's being proposed here. Today in Swift, === has a very specific meaning, which is that both operands are reference types and they are referentially the same object. It would be really harmful for fundamental value types like Array<Element: Equatable> and String to implement both == and ===, because that would become a really easy source of subtle typos/bugs. It would also be a rough teaching experience to have to explain when to use == or === for a specific set of value types ("you want ==, === does handwavy things that you don't need to worry about right now..."). It's easier to teach today because the latter just doesn't compile, so you don't have to mention it until you start teaching reference types.
(Sure, the same thing about confusability of the operators can happen with class types today, but it's much less common for classes to implement Equatable than for value types.)
This is fundamentally a low-level performance-driven operation and its usage should be very obvious at the call site, not given the privilege of an operator that would make it blend in easily with other common value-type operations.