The "block size" matters for Merkle-Damgård functions because the HMAC security proof relies on that block size. For other functions, and in particular sponge functions, the block size for HMAC is mostly a matter of convention.
In fact, HMAC uses two nested calls to the function because such a construction is more or less needed to ensure security with MD function. This is widely considered to be a flaw in the Merkle-Damgård construction. Sponge functions are supposed not to have that flaw, so a simple $H(K || M)$ should be a secure MAC (assuming a proper definition for the concatenation to avoid ambiguities).
So why HMAC is not formally needed to make a MAC out of a sponge function, it can still be used, and any "block size" will work, with no problem to security. The only constraint is that the block size must be larger than the hash function output size, because HMAC mandates that when the key is longer than the block size, the hash of the key is used instead; this cannot work if the block size is smaller than the hash output.
In the case of Keccak, the submission package states in section 5.1.1:
Several standards that make use of a hash function assume it has an input block length and a
fixed output length. A sponge function supports inputs of any length and returns an output
of arbitrary length. When a sponge function is used in those cases, an input block length and
an output length must be chosen. We distinguish two cases.
For the four SHA-3 candidates where the digest length is fixed, the input block length
is assumed to be the bitrate r and the output length is the digest length of the candidate
n ∈ {224, 256, 384, 512}.
For an instance with variable-length output, the output length n must be explicitly
chosen to fit a particular standard. Since the input block length is usually assumed to
be greater than or equal to the output length, the input block length can be taken as an
integer multiple of the bitrate, mr, to satisfy this constraint.
And then, in section 5.1.3:
HMAC [1, 25] is fully specified in terms of a hash function, so it can be applied as such using
one of the Keccak candidates. It is parameterized by an input block length and an output
length, which we propose to choose as in Section 5.1.1 above.
Apart from length extension attacks, the security of HMAC comes essentially from the
security of its inner hash. The inner hash is obtained by prepending the message with the
key, which gives a secure MAC. The outer hash prepends the inner MAC with the key (but
padded differently), so again giving a secure MAC. Of course, it is also possible to use the
generic MAC construction given in [6], which requires only one application of the sponge
function.
From the security claim in [12], a PRF constructed using HMAC shall resist a distinguishing
attack that requires much fewer than 2c/2 queries and significantly less computation than
a pre-image attack.
So, in the case of Keccak (thus, presumably, SHA-3 too), the "block length" for HMAC is to be $1600 - 2x$, where $x$ is the hash output length, in bits (the "bitrate" and the "capacity" are such that their sum is $1600$, and the capacity is twice the hash output length).
