You're fighting against two things here:

Why do operators exist in languages in the first place? What is the virtue of operators over functions/methods?

In most languages, operators are not really implemented as simple functions. They might have some function scaffolding, but the compiler/runtime is explicitly aware of their semantic meaning and how to translate them efficiently in to machine code. This is much more true even as compared to built-in functions (which is why most implementations also don't include all the function call overhead in their implementation). Most operators are higher level abstractions on primitive instructions found in CPUs (which is partly why most operators are arithmetic, boolean, or bitwise). You could model them as "special" functions (call them "primitives" or "builtins" or "native" or whatever), but to do that generically requires a very robust set of semantics for defining such special functions. The alternative is to have built-in operators that semantically look like user defined operators, but which otherwise invoke special paths in the compiler. That runs afoul of the answer to the second question...

Aside from the machine translation issue I mentioned above, at a syntactical level operators aren't really different from functions. They're distinguishing characteristics tend to be that they are terse and symbolic, which hints at a significant additional characteristic they must have to be useful: they must have broadly understood meaning/semantics to developers. Short symbols don't convey much meaning unless it is short hand for a set of semantics that are already understood. That makes user defined operators inherently unhelpful, as by their very nature they aren't so broadly understood. They make as much sense as one or two letter function names.

C++'s operator overloads provides fertile ground for examining this. Most operator overload "abuse" comes in the form of overloads that break some of the semantic contract that is broadly understood (a classic example is an overload of operator+ such that a + b != b + a, or where + modifies either of its operands).

If you look at Smalltalk, which does allow operator overloading and user defined operators, you can see how a language might go about doing it, and how useful it would be. In Smalltalk, operators are merely methods with different syntactical properties (namely, they are encoded as infix binary). The language uses "primitive methods" for special accelerated operators and methods. You find that few if any user defined operators are created, and when they are, they tend not to get used as much as the author probably intended for them to be used. Even the equivalent of an operator overload is rare, because it is mostly a net loss to define a new function as an operator instead of a method, as the latter allows for an expression of the semantics of the function.