Is this variation of Arrange-Act-Assertion for automated UI testing an anti-pattern

I am writing selenium tests to do regression tests against end-to-end business processes. Typically, the scenarios have been created by manual testers, and have test steps and expected outcomes.

My pattern becomes Arrange, Act-Assert, [ ... Act-Assert] potentially with another Assert at the end.

Whilst I could break these into many smaller tests, the steps don't typically make sense out of context, e.g. going through a wizard/multi-step process.

My tests have a fluent API. Verify (extension method) calls Assert.IsTrue on the condition, and my tests end up looking something like (this very contrived example):

PageModelFactory.Get<StartPage>() 
  .Login(...).Verify(x => x.IsLoggedIn)
  .GoToUserSettings()
  .SetAlternateEmailAddress(...).Verify(x => x.EmailAddressValidIndicatorDisplayed)
  .SaveChanges().Verify(x => x.SuccessMessageDisplayed)

The benefits I can see are that the tests align closely with the style that "testers" write the regression tests in, and it will fail-fast if an expected result for a step fails.

The downsides are that I will have to do a bit more to determine exactly what the cause of error was (which I could wrap into the Verify method), and that it moves away from the A-A-A pattern.

Are there any other benefits/concerns with this approach that would affirm my usage of it, or point me back towards pure A-A-A?