This question is complicated by exactly what we mean by "ownership". There are several different models of ownership in the literature, each with different implications (owners-as-dominators, owners-as-modifiers, owners-as-accessors, dynamic ownership, multiple ownership, ...), each has generally been imposing a correctness concept on the object graph, and what Rust has doesn't match any of them. On the other hand, they have largely been envisaging Java-like systems, so they are a semantic match here.
The work that originally introduced the concept of ownership types¹ noted:
It is nonsensical to infer which objects are representation; such information is part of the programmer’s intention.
In this perspective, to own an object is to have it as part of your inner representation, and that can only be a design choice: it's a correctness constraint on unauthorised state changes. There's no way to detect what is inherent to the object, and so outside access is an error, and what is intended to be an external shared value, and so outside access is expected. For rejecting incorrect programs, some imposed idea of what is correct is required, and this is why "ownership inference" is sometimes seen as a contradiction in terms.
Nonetheless, there have been ownership-inference systems, notably Huang et al. at ECOOP 2012 Inference and Checking of Object Ownership². This approach infers many valid typings across the whole (Java) program based on how values are accessed, and attempts to choose the "best" one. This generation exhaustively produces the consistent ownership annotations the program permits and winnows them down to one. The heuristic for "best" is about finding a deep ownership tree, seen as providing the best encapsulation, then choosing the tightest modifiers.
A key element is that it will be wrong if the program is, or at least a more general owner will be inferred than the programmer may have intended. However, for the compilation optimisation case that it seems you're interested in, this could well be good enough! As long as it identifies some inlineable objects, that's an improvement.
This system supported both -dominators (classical ownership) and -modifiers models, with only very rare annotations in the former case and none in the latter. Owners-as-dominators specifically prohibits all incoming pointers, so these are strong inlining candidates. The inference system occasionally requires programmer input to resolve conflicts here, which could come from explicit manual annotations, but they estimate these at six per thousand lines of code. They give 40% of all objects as being representation, though not all of these are likely to be real inlining candidates, so that is a cap on how much impact there could be. The actual tool (for Java) is available here.
Subsequent work has investigated other variants, immutability, and more interactive systems. Feeding back run-time information to the compiler may also give useful information about what arises in practice, which could inform automatic inference or determine layout itself. All ownership systems may be imposing more structure on the program than you want for purely identifying inlineable or GC-excluded objects, rather than correctness or concurrency-safe code, but the other properties they provide may be useful as well.
¹David G. Clarke, John M. Potter, and James Noble. 1998. Ownership types for flexible alias protection. In Proceedings of the 13th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA '98). Association for Computing Machinery, New York, NY, USA, 48–64. https://doi.org/10.1145/286936.286947
²Huang, W., Dietl, W., Milanova, A., Ernst, M.D. (2012). Inference and Checking of Object Ownership. In: Noble, J. (eds) ECOOP 2012 – Object-Oriented Programming. ECOOP 2012. Lecture Notes in Computer Science, vol 7313. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-31057-7_9