It's always difficult to comment on parts of code without knowing the whole thing, but randomly assuming there's nothing in the other stuff that's material, I've noticed a few things you could improve. Idiomatically it's not bad, just a few missing details.

struct User
{
    std::string name;
    int age;

    User(std::string n) : name(std::move(n)) {}
};

Notice the extra std::move - this eliminates a pointless copy of the string. There's quite a few other places. The general rule is that if you don't need the source object anymore, std::move the last usage. This is particularly good for functions which only reference things one time (as in the above).

For the entity details, you can make life considerably simpler on yourself by using std::function. One of the things people often miss when coming from other languages is how much C++ lambdas can really simplify things. Consider for example:

class Session
{
    std::vector<std::function<std::string()>> items;

public:
    template <typename T>
    void store(std::shared_ptr<T> entity) {
        items.push_back([=] {
           return *entity;
        });
    }

    void save_changes() {
        for (auto&& it : items) {
            auto json = it();
            std::cout << json << std::endl;
        }
    }
};

In this case the std::function can perform small buffer optimisation, eliminating the need for a heap reference. Another benefit is that it's a lot less verbose and keeps everything by value, which is more idiomatic. It's a bit less pleasant if you're trying to keep multiple functions that way though. Even if you decide to stick with the interface (which is not an invalid decision; depends a lot on details not shown here) use a unique_ptr, not a shared_ptr. There's no need for refcounting here.

In fact, the details of keeping a reference to the entity are arguably poor here as well. I've been thinking about how to handle figuring out how to handle serialising the entity, and I think it would be best to just take the serialisation function as the argument to store in the first place. Then the user doesn't need to keep their entities on the heap if they don't need to, and you don't have to worry about ADL or interfaces for figuring out how to serialise.

For example, class Session { std::vector<std::function<std::string()>> items;

public:
    template <typename T>
    void store(std::function<std::string()> serialise) {
        items.push_back(serialise);
    }

    void save_changes() {
        for (auto&& it : items) {
            auto json = it();
            std::cout << json << std::endl;
        }
    }
};

int main()
{
    User user;

    Session session;
    session.store([&] { return to_json(user); });

    user->age = 2;

    session.save_changes();
}

If you used an interface for the contents of items, those objects being held there are not the lifetime of the entity, though. That is only the lifetime of the Session, so unique_ptr can be appropriate there.

The advantage of the approach I have suggested where you simply take the serialisation function directly is that the user can choose how the lifetime works. They can use a shared approach as you have used here, but they can also use a fixed lifetime approach as I have shown- or indeed, any other lifetime that works for them.

One of the things I found in the C++ community is that there is always a part who will go nuts over the slightest heap allocation or any perceived inefficiency, even if in reality it's totally meaningless (e.g. a couple extra allocations per entity). APIs that allow them to avoid allocating on the heap if possible tend to be more successful.