You can get most of the way there with sa_column to decouple the Python attribute name from the DB column name, plus computed_field for the derived accessor:

from sqlalchemy import Column, Integer
from sqlmodel import SQLModel, Field
from pydantic import computed_field


class Foo(SQLModel, table=True):
    field1_: int = Field(sa_column=Column("field1", Integer))
    field2_: int = Field(sa_column=Column("field2", Integer))
    field3_: int = Field(sa_column=Column("field3", Integer))

    @computed_field
    @property
    def fields(self) -> list[int]:
        return [self.field1_, self.field2_, self.field3_]

sa_column=Column("field1", ...) maps the attribute to the real (ugly) column name, so at least the Python-facing name can be whatever you want.

The part that's worth being upfront about: there's no way to make field1_/field2_/field3_ truly invisible to the language server the way a real private attribute would be. Both SQLAlchemy's mapper and Pydantic's model machinery need these to exist as ordinary class attributes to work at all — they have to be declared where the type checker can see them, so autocomplete will always be able to find them. A leading underscore is only a convention here, not enforcement (and a leading double underscore would trigger Python name-mangling and break both ORMs, so that's not an option either).

If you want the raw columns to be fully absent from what callers/IDEs see, the usual way out is a layer of indirection: keep the table model private to your data-access code (only that module ever imports it), and expose a separate plain (non-table=True) SQLModel/Pydantic model to the rest of the app that only defines fields, built via Foo.model_validate(row) or a small mapper function. That costs you an extra class and a mapping step, but it's the only way to actually remove field1..3 from the type surface everyone else works with, rather than just discouraging its use.