I want to begin this by first addressing the problem space here as I see a bit of misunderstanding regarding both "eventual consistency" and DDD. 

DDD is a *design* process that understands real-world problems can sometimes reach a level of complexity that they cannot be cleanly separated and modeled into completely independent units. That is, *process* itself can have rules and when such a situation arises, eventual consistency *can be* employed to offer a solution. I don't read the quote you offer from the blue book (in the OP comments) as advocating for any mode of consistency, rather pointing out that eventual consistency is often a desirable and sometimes necessary attribute within a system of which we need to be aware when forming our expectations. 

Whether or not a given system needs to employ an eventual consistent paradigm should be determined through analysis of its requirements in terms of scaling, not through analysis of it's design (though the former can *certainly* inform the latter). This decision should not be made lightly (and doesn't have to be all-or-nothing), because the trade-offs are steep and often require *much* greater complexity in terms of implementation where employed.

As to your system, I think you may have complected a couple of things together.

The first is that an `Auction` would be better understood/implemented as a `Saga`/`ProcessManger` rather than an `Aggregate`. That is, an `Auction` represents a grouping of related events that must be managed in terms of process. In this way, your `Auction` is given the responsibility to oversee *it's own* consistency and can therefore usefully abstract business requirements. 

This flows into the second issue of not separating responsibilities into the correct entities. The issue you describe is predicated on your `Auction` needing to "ask" for an account balance. Clearly, it should be the responsibility of your `Account` (`UserBalance` is a confusing name) to keep track of the current balance. Therefore, it must also be responsible for creating a new `Bid`. In this way, we can cleanly separate the logic necessary for verifying an account balance from that of placing bids. Nobody at an auction cares about account balances, so let's keep that separate from our auction. Think of it like this, "how does an auction work?". It can be modeled relatively simply:

PlaceBidHandler (moves money into escrow):
    
    // throws NotFound
    account = accounts.Find( cmd.UserId ) 
    
    // throws InsuficientFunds or raises `BidPlaced`
    account.PlaceBid( cmd.AuctionId, cmd.LotNumber, cmd.Amount ) 


SubmitBidHandler (keeps track of all `Bids` or maybe just highest `Bid`):

    // throws NotFound
    auctioneer = auctioneers.Find( cmd.AuctionId ) 
 
    // raises Outbidded
    auctioneer.ReceiveCompetingBid( cmd.UserId, cmd.LotNumber, cmd.Amount ) 


RevokeBidHandler (removes money from escrow):

    // throws NotFound
    account = accounts.Find( cmd.UserId ) 

    account.RevokeBid( cmd.AuctionId, cmd.LotNumber ) 


The `Auction` (which *mediates* the process) is simply responsible for reacting to `BidPlaced` events in a way to trigger `SubmitBid` **OR** `RevokeBid` commands (should `NotFound` be thrown), and reacting to `Outbidded` events in a way to trigger `RevokeBid` commands.

If you would like to keep `Account` and `Auction` in separate contexts (you don't want `Account.PlaceBid`), this can be modified further to add an extra layer along the lines of: `PlaceOrder -> PaymentReceived -> PlaceBid` (in this case ordering a `Bid` and debiting account) and `BidRevoked -> RefundPayment` to cleanly separate accounts from auctions.