Yes, AES is just used as a 128 bit / 16 byte block cipher in this scheme. The paper specifies:
Poly1305-AES feeds each nonce $n$ through $AES_k$ to obtain the 16-byte string $AES_k(n)$.
There is no mention of AES without this key $k$ or nonce $n$. So, as far as AES - the block cipher - is concerned, $k$ is the key and the nonce $n$ is the data / message.
The reason that no mode-of-operation such as ECB / CBC is mentioned is that the specification uses the block cipher itself, without any mode. If you only have access to AES-ECB then you should use ECB without padding (or, if padding is always performed, just taking the first 16 bytes after feeding the nonce). You can use CBC with an IV using 16 zero valued bytes in a similar manner. Or you could use CTR with the nonce $n$ and an all zero plaintext of 16 bytes - probably makes most sense as CTR mode won't pad.
FYI the reason that you don't find an example in a TLS library is possibly that they use ChaCha20/Poly1305 where the ChaCha20 cipher is used instead of AES
From RFC 7905 section 1:
The variant of ChaCha used in this document has 20 rounds, a 96-bit
nonce, and a 256-bit key; it is referred to as "ChaCha20". This is
the conservative variant (with respect to security) of the ChaCha
family and is described in [RFC7539].
From RFC 7539 section 2.8.1:
otk = poly1305_key_gen(key, nonce)
counter = 0
block = chacha20_block(key,counter,nonce)
chacha20_block is used instead of AES - they did say it was nothing special right? Note that the encryption then helpfully starts with counter 1 instead of zero, so it is a simple continuation of ChaCha20...