As with databases of password hashes, the traditional approach to prevent dictionary based attacks is to make computing hashes (or in this case verifiers) from passwords costly enough.
In the case of SRP, the obvious way to do this is to choose a group which is large enough. (In any case, it must be large enough to resist cryptanalysis, as with RSA or DH.)
Obviously, increasing the size of the group will also slow down both clients and servers.
Another possibility is to replace SHA-1 with another hash function as is suggested in section 3.2 of RFC 2945. The salted SHA-1 construct used in SRP-SHA1 can be replaced by another message digest, or by HMAC or by a password hashing function.
In my opinion, using a good password hashing function such as Argon2 or BCrypt or PBKDF2 instead of SHA-1 makes sense. Doing this increase the cost of dictionary attacks without having any impact on server performance. (Client performance is impacted though.) On the other hand, this does not improve resistance to cryptanalysis.
SRP is designed to protect passwords in a threat model which assumes an attacker can gain access to the memory of the server. Thus, SRP is designed to be secure in a context where an attacker would have access to your master password.
This above also means SRP actually competes with password managers, the later being a more widely deployed solution. SRP is mostly useless if your users already use password managers with a unique password for each site.
Encrypting stored verifiers is essentially the same as "peppering" a password database. This adds quite a lot of complexity. Whether this improves the security of the system is not obvious.
This only makes sense if you assume the attacker has access to the database but not to the server (while using SRP only makes sense if you assume the attacker has access to the server), your master password has good entropy and your encryption code is properly written (IVs are properly generated...)
Regarding your usage of Argons2, you should make the parameters fixed: use as much memory and processing power as you can afford. Do not make the parameters depend on the password.