Yes you can make any controller to overwrite a specific route and its action.

I have overwritten Pow registration controller with just a regular controller. For my understanding , i kind of added made it look alike. When you ran mix pow.phx.gen.templates, it creates a pow/registration/files inside lib/templates. I did the same added pow/registration_controller inside lib/controllers.

Entire Code Block

I created a module and named it pow/.
scope "/" do
    pipe_through [:browser]
    resources "/registration", MyAppWeb.Pow.RegistrationController, singleton: true, only: [:create]
  end

controller:
defmodule MyAppWeb.Pow.RegistrationController do
  use MyAppWeb, :controller

  # def new(conn, _params) do
  #   # We'll leverage [`Pow.Plug`](Pow.Plug.html), but you can also follow the classic Phoenix way:
  #   # changeset = MyApp.Users.User.changeset(%MyApp.Users.User{}, %{})

  #   changeset = Pow.Plug.change_user(conn)

  #   render(conn, "new.html", changeset: changeset)
  # end

  def create(conn, %{"user" => user_params}) do
    # We'll leverage [`Pow.Plug`](Pow.Plug.html), but you can also follow the classic Phoenix way:
    # user =
    #   %MyApp.Users.User{}
    #   |> MyApp.Users.User.changeset(user_params)
    #   |> MyApp.Repo.insert()

    case MyApp.Users.create_user_using_referral(user_params) do
      {:ok, user} ->
        conn
        |> put_flash(:info, "Welcome, Lets find your spouse!")
        |> redirect(to: Routes.dashboard_path(conn, :index))
      {:invalid_code, changeset} ->
        conn
        |> put_flash(:error, "You have entered an invalid code")
        |> render("new.html", changeset: changeset, action: Routes.registration_path(conn, :create))
      {:error, changeset} ->
        conn
        |> put_flash(:error, "Please correct the errors")
        |> render("new.html", changeset: changeset, action: Routes.registration_path(conn, :create))
    end
  end
end

And i used pow custom context as well.

defmodule MyApp.Users do
   use Pow.Ecto.Context,
        repo: MyApp.Repo,
       user: MyApp.Users.User

  def create_user_using_referral(params) do
    case params["referral_code"] do
      nil -> pow_create(params)
      "" -> pow_create(params)
      code ->
        case MyApp.Trial.get_by_referral_code(code) do
          nil ->
            changeset = User.changeset(%User{}, params)
            Ecto.Changeset.add_error(changeset, :referral_code, "Entered code is invalid", validation: :invalid)
            {:invalid_code, changeset}
          referral_code ->
            pow_create(params)
        end
    end
  end
end

You can both customize messages and redirect paths. The conn is passed along so you could even add some conditional based on, e.g. the @changeset assign for the message or route.

But the way @tenzil resolved it is what I prefer since it’s much more explicit, and it makes sense when you e.g. add controller test to it. One idea I have of Pow is that in most cases it should work more as a helper than a framework, so whenever you customize stuff you basically write it all out so it’s easy to test, understand and take control of rather than depending on the library.

I definitely want to ease these steps so please do let me know what could be improved!

No, but the context modules are minimal since they use macros. It’s done this way so you only have to override the methods that you want custom logic for, and let Pow handle the rest. The callbacks should be used as reference for what to override.

As for controllers, I think it’s best to let developers decide the design rather than having a generator set it up. You only need to use Pow.Plug methods, Pow controllers are extremely thin. There is a guide in the docs that shows how to set up custom controllers: Custom controllers — Pow v1.0.15

In PowAssent it’s more complex though.

I set up Pow and PowAssent and got a new Phoenix app running locally with email and Github login. After creating account with email and a password, I logged out and then tried an Oauth login via a Github account. That Github account is also under the same email address. Rather than logging me in or maybe asking me to verify my existing password, it asks for another email to link to the Github auth (which seems like a bad idea).

We had a discussion about this recently on Github. TLDR; it works like this for security, but the UX would be much better (as you wrote) if the user had the option to auth themselves to link up the provider instead of selecting another user id or having to exit the flow and sign in first. I plan to look into this as soon as I got free time for it.