I'm not really clear about what you're describing, but a few thoughts... log(t(A, X)) * log(t(A, X)) is log(t)^2, not 2log(t). Not sure if "split memory not by halves but by interleaving fragments" is crucial, but splitting by anything other than halves leads to complexity > log2. The more unbalanced the splits, the worse the complexity. The upper bound is O(n). It seems you're proposing the creation of a (merkel) tr…
You understood mostly right, but see my another comment for more detailed proof that does address this issue by ignoring zero-filled fragments of INFINITE memory. There is no "n".
Storing one value into a tree is O(log(X)). However, storing all possible values for X bits is 2^X operations, each of which requires log(X) sub-operations to store it.
Pre-calculating all possible input-output mappings requires looking at every possible input value. Thats 2^X.
That isn't what P =? NP is looking for. The forward function, A, isn't a big look-up table. Instead, it's a much smaller set of transformational steps. So if A(y) is defined as y+1, you can code it with about X primitive logical operations. One operation could be "output[least significant bit] = xor(input[least significant bit], 1)". That operation causes a transformation to every single input value, and is thus very powerful and economical. Other operations would ripple the carry to the more significant bits; the next-to-least-significant operation transforms half of the input values, the next bit affects one quarter of them, and so on.
P =? NP asks if it's always possible to come up with a reasonably small set of transformations that go the opposite way. You can't do that with a process that looks at the discrete values. If it's possible it will require some kind of comprehension of the algorithm's structure. We can't (in polynomial time) create an inverse of "y+1" by listing what happens for each possible input value. We need to recognize that the inverse function is "result - 1" and provide the primitive operations for that.